OK, here's a few smaller steps that I've done:
1) Checked in the tiger defconfig file into xenlinux
2) Checked in the asm-xsi-offsets.c file and the changes
to arch/ia64/Makefile to build it. (NOTE: It appears
that this change results in a complete rebuild for
every file change? Please confirm.) Also, for now
I've left SHAREDINFO_ADDR and SHARED_ARCHINFO_ADDR
to be the same until I understand this change better.
3) Checked in syntactic changes to several files to
make it easier to convert between vcpu_info.arch
being a pointer or not a pointer (and possibly
adding an extra level of indirection).
4) Added the define of IA64_TR_ARCH_INFO in kregs.h
It will be necessary to regenerate the remaining patches, but:
1) First we need to settle on the approach for vcpu_info.arch
and, if its going to be a pointer and requires a change
to common, we will need to get that change into common first.
2) Please start using the Intel hg staging tree.
3) Please separate unrelated changes into separate changesets.
4) I'm unhappy with exposing all the VTI VMX struct info to
xenlinux. Is there a better way?
Dan
> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins)
> Sent: Wednesday, July 27, 2005 12:13 PM
> To: 'Yang, Fred'
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] RE: Patches for ia64
> arch_vcpu_info_t merge
>
> Hi Fred --
>
> I am just back in the office and have a number of things I need
> to catch up on. I have not yet successfully run the patches.
> However, as I discussed directly with Eddie, I think we need
> to go back and make the changes more carefully and one step at
> a time. In particular, there are common changes that I don't
> think Keir will accept. So the first step will be to revisit
> these and make the necessary (ia64-only) patch to handle this
> differently. I have already emailed Eddie about this.
>
> I will try to apply some of the parts of the patchset that
> are independent so we are not dealing with so many moving
> parts.
>
> Dan
>
> > -----Original Message-----
> > From: Yang, Fred [mailto:fred.yang@xxxxxxxxx]
> > Sent: Wednesday, July 27, 2005 12:02 PM
> > To: Magenheimer, Dan (HP Labs Fort Collins)
> > Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-ia64-devel] RE: Patches for ia64
> > arch_vcpu_info_t merge
> >
> > Dan,
> > Can you run the patches on your system yet? We can also
> > create on the pure EL4 enviroment, though we were seeing a
> > lot of warning message of "vcpu_translate: bad address ....";
> > but the domU was still up with slow boot time.
> > Attached new patches to work around "copy_to_user" issue on
> > top of previous patches I sent out on 7/20
> > Please let us know if any issue .
> > Thanks,
> > -Fred
> > Tian, Kevin wrote:
> > > Hi, Dan/Matt,
> > > We can't reproduce your problem here, with validation
> > that latest hg
> > > tree with/without this patch all boots to single user
> mode of domU.
> > >
> > > Hg source: xen(5810), xeno(16)
> > > Distribution: RHEL3
> > > Python: 2.4.1
> > > Hardware: Tiger4/Madison
> > > Disk image: A 50M subset of RHEL3
> > >
> > > 1. We can boot Dom0 on Tiger4 after solving following 2 issues:
> > > A. PAL code should be always mapped by ITR with current
> > rr7. However
> > > currently it's only inserted at xen init, with IDLE's
> rr7. Then when
> > > emulating PAL for Dom0, we need a new mapping with Dom0's rr7. Or
> > > else we saw MCA. Now we temporarily recovered back to
> > > pal_emulator_static.
> > >
> > > B. Now virtual terminal is disabled in xenolinux by default, to
> > > avoid confliction with Xen console for domU. However this also had
> > > influence to dom0, especially when we failed to setup DNS and thus
> > > failed to connect by network. :-(. So finally we just compiled two
> > > vmlinux - xeno-vmlinux with CONFIG_VT on, and xenU-vmlinux with
> > > CONFIG_VT off. Except this option, all rest stuffes are
> > identical.
> > >
> > > 2. After above steps, then we can setup environment for test. With
> > > some time spent on binding disk image, finally both patched and
> > > unpatched environments can boot domU into single user mode.
> > > (Excellent response speed!). Only uncertain issue is too many
> > > warnings "about to deliver early timer to domain 0!!!" for both
> > > tests...
> > >
> > > (I didn't see "vcpu_translate" warning on above environment)
> > >
> > > Could you check whether there's any mismatch in this process as
> > > yours? If still same, could you please post your environment
> > > somewhere, so that we can download and verify? Like your
> > distribution
> > > version, detail steps, and disk image, etc.
> > >
> > > Thanks,
> > > Kevin
> > >> -----Original Message-----
> > >> From: Dong, Eddie
> > >> Sent: Friday, July 22, 2005 10:17 PM
> > >> To: Yang, Fred; Tian, Kevin
> > >> Subject: FW: [Xen-ia64-devel] RE: Patches for ia64
> arch_vcpu_info_t
> > >> merge
> > >>
> > >> New found that I didn't meet yesterday. Does kevin ever
> set up the
> > >> environment successfully?
> > >>
> > >> Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > >>> It got much farther this time, starting redhat init, but
> > >>> died with what appears to be a null pointer dereference.
> > >>>
> > >>> (XEN) vcpu_translate: bad address 0000000000000000,
> > >>> viip=a000000100065b20, vipsr=0000021008026018,
> > iip=0000000000000000,
> > >>> ipsr=0000101208026018 continuing
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx]
> > >>>> Sent: Friday, July 22, 2005 7:04 AM
> > >>>> To: Magenheimer, Dan (HP Labs Fort Collins)
> > >>>> Subject: RE: [Xen-ia64-devel] RE: Patches for ia64
> > >>>> arch_vcpu_info_t merge
> > >>>>
> > >>>> Dan:
> > >>>> Yes I realized that too (patch failure), sorry for
> > >>>> that. So please use the old patch + delta I sent u
> this morning.
> > >>>> also resent. Thx,eddie
> >
> >
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home