This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: Multiple domains up on a bit old Rev
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 20 Sep 2005 12:13:57 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Sep 2005 19:13:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-topic: 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?


> -----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

<Prev in Thread] Current Thread [Next in Thread>