Hi Kevin --
The attachment you sent is garbled. It may have 16-bit
(non-ASCII) characters in it?
If you point me to the xen-unstable changeset that Keir's
fix is in, I may grab the whole changeset and apply it,
which may simplify merging with xen-unstable later
(unless you think other parts of Keir's changeset will
break your multiple-domain work?)
Dan
> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Wednesday, September 21, 2005 6:03 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: Multiple domains up on a bit old Rev
>
> I also couldn't reproduce same result on tip last night.
> However today I made it. No special steps compared to previous flow.
>
> In the start, I found out the image size calculated for xenU
> kernel is incorrect (By check /var/log/xend-debug.log), which
> made parseelfimage in control panel failed to retrieve ELF
> header info and thus failed in "xm create".
>
> However when I added some debug information to libxc,
> everything worked well then and xenU can boot to shell. Then
> even when I remove those debug information and roll back,
> xenU still worked.
>
> So I doubt there's some environmental dirty between first and
> second try. Of course it's also possible that some
> intermittent bug hides behind. Maybe you can make a fresh try
> tomorrow and see whether it works for you then.
>
> BTW, please add attached changeset into xen-ia64-unstable.hg,
> which was made by Keir last week to remove bad lines in
> xen-backend.agent. That's the reason why I always failed to
> see "physical-device" created in xenstore.
>
> Thanks,
> Kevin
>
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins)
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005年9月21日 3:14
> >To: Tian, Kevin
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: Multiple domains up on a bit old Rev
> >
> >I checked in the changes but am unable to reproduce your
> >success on tip, even with the public structure changes
> >propogated. I think only arch-ia64.h changed, as part
> >of Anthony's merge_cpu_2 patch, and arch-ia64.h gets
> >auto-copied when xenlinux is rebuilt so I can't explain
> >why it would work on rev 6857 and not on tip.
> >
> >Can you get reproduce your success on tip and, if so,
> >describe the steps?
> >
> >Thanks,
> >Dan
> >
> >> -----Original Message-----
> >> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> >> Sent: Tuesday, September 20, 2005 7:29 AM
> >> To: Tian, Kevin; Magenheimer, Dan (HP Labs Fort Collins)
> >> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Multiple domains up on a bit old Rev
> >>
> >> OK, attached patches can make multiple domains working
> again, however
> >> with a bit old Rev upon which I'm working consistently:
> >>
> >> Xen-ia64-unstable.hg: Rev 6857
> >> Xenlinux-ia64: Rev 37
> >>
> >> I tried the latest xen-ia64-unstable (6867) and failed at
> "xm create".
> >> This is reasonable since there're some public structure
> >> changes in a few
> >> new changesets. Lucky thing is, that problem is easy to debug since
> >> these changes are well controlled, not like past 1.5 weeks
> to struggle
> >> with some unknown feature changes in common part. ;-)
> >>
> >> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
> >>
> >> Some interesting issues found related to two small patches:
> >> 1. Only "xm console 1" and "Ctrl + ]" can make xenU
> forward progress,
> >> and however still failed to connect blkback later.
> >> [Reason] Previous event injection on XEN/IPF only set vIRR bit
> >> when evtchn_set_pending. However with the latest xenlinux
> code, it's
> >> possible for xenlinux to set pending indication and selector when
> >> unmasking some pending event channel. This path has
> nothing to do with
> >> vIRR bit.
> >>
> >> [Solution] We should check event pending every time when
> >> checking pending interrupts before returning to guest.
> >>
> >> 2. After fixing first issue, nested event is injected when
> first event
> >> is still in handle with lock held. Then dead lock happens at end of
> >> "xend start".
> >> [Reason] Due to same logic as above, xenlinux may set pending
> >> indication and re-trigger pending event by
> force_evtchn_callback. On
> >> x86, this stub just does a dummy xen_version hypercall and
> >> pending event
> >> will be injected back when leaving hypervisor. However on IA64,
> >> force_evtchn_callback is incautiously made invoking
> evtchn_interrupt()
> >> directly, while the former may be called with lock held.
> >>
> >> [Solution] Just let force_evtchn_callback as empty for simple
> >> now.
> >>
> >> 3. There's one xenstore node named "physical-device",
> which contains
> >> major/minor number of device taken as disk for xenU.
> However that node
> >> is not created automatically and thus later blkfront/blkback
> >> communication failed since no virtual disk is found
> >> [Reason] Dunno yet. I sent a mail to xen-devel, and hope someone
> >> can answer the puzzle for me. ;-)
> >>
> >> [Solution] This one really took me much time, and below is a
> >> temp hack for you to try out. (Don't check-in)
> >>
> >> diff -r 7f9acc83ffcd tools/python/xen/xend/XendDomainInfo.py
> >> --- a/tools/python/xen/xend/XendDomainInfo.py Mon Sep 19
> >> 17:08:20 2005
> >> +++ b/tools/python/xen/xend/XendDomainInfo.py Tue Sep 20
> >> 21:16:13 2005
> >> @@ -419,7 +419,8 @@
> >> back = { 'type' : type,
> >> 'params' : params,
> >> 'frontend' : frontpath,
> >> - 'frontend-id' : "%i" % self.domid }
> >> + 'frontend-id' : "%i" % self.domid,
> >> + 'physical-device' : "%li" %
> >> blkdev_name_to_number(params) }
> >> xstransact.Write(backpath, back)
> >>
> >> return
> >>
> >> Thanks,
> >> Kevin
> >>
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home