[Xen-ia64-devel] RE: Multiple domains up on a bit old Rev

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

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