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
hg_md_up_0920_xeno
Description: hg_md_up_0920_xeno
hg_md_up_0920_xen
Description: hg_md_up_0920_xen
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home