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

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

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