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


Re: [Xen-ia64-devel] One unstablity in fast syscall path

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] One unstablity in fast syscall path
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Tue, 13 Jun 2006 09:54:57 +0200
Delivery-date: Tue, 13 Jun 2006 00:50:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <386718549BA50E498DA75F3C0518CEEC0F1E46@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <386718549BA50E498DA75F3C0518CEEC0F1E46@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mardi 13 Juin 2006 02:36, Tian, Kevin a écrit :
> Recently we kept seeing intermittent domU creation failure after
> creating
> VTI domain. After some debug, we found it caused by following
> changeset:
> changeset:   10238:b27139d8c1e1
> user:        awilliam@xxxxxxxxxxx
> date:        Sat Jun 03 11:16:47 2006 -0600
> summary:     [IA64] paravirtualize vdso
> There're several privileged accesses to vPSR in gate page, and
> previously it's done directly by triggering GP fault without xenlinux
> changes. Rev 10238 tries to para-virtualize those instructions by
> introducing two new hyperprivops. Now a simple assumption is forced to
> distinguish break immediate by checking vPSR.ic. People thought there's
> no break instruction with psr.ic off in xenlinux. So any break with
> vpsr.ic off
> is considered as a hyperprivop between domain and hypervisor. Based on
> this assumption, explicit vpsr.ic clearance is required before
> hypercall,
> and then recover required after.
> OK, that works, for most time because normally those hypercalls are
> issued within kernel text segment which is mapped by TR. So after
> hypervisor finished service for fast hypercall, xen can always RFI to
> exact
> resume point in xenlinux even when ITLB miss happens since that
> resume point can be found by vTR.
> However, gate page is not mapped by TR, and thus populating PSR.ic at
> non-TR-mapped segment is even mad in native environment. In our
> observation, when backing to gate page after servicing fast hypercall,
> ITLB miss happens but there's no guest entry in vTLB and VHPT. Thus
> xen injects a nested dtlb fault to xenlinux (vPSR.ic is still off) which
> is
> undesired to crash domU.
> That's the real problem, though we're not sure why this phenomenon is
> easier to be reproduced after creating VTI domain. Quick/easy solution
> can be to roll back above changeset to ensure tree stability first, and
> then
> community needs to think more robust solution later.
Good work !

After reading some Xen/ia64 source, I think we'd better not to use vpsr.ic for 
fast hypercall: it has some interractions with vpsr.ic flag!

I'd vote for creating a new paravirtualized register: xen_break (or 
xen_hyperprivop): when this new register is set, breaks are hyperprivop, when 
not set breaks are reflected.

Of course, changing the logic requires some work and careful checks.


Xen-ia64-devel mailing list