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] One unstablity in fast syscall path

To: "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] One unstablity in fast syscall path
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 13 Jun 2006 08:36:05 +0800
Delivery-date: Mon, 12 Jun 2006 17:36:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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-index: AcaOLVEOk4A5OuslRseib+sB7p3pkgAAs4+AABPzmIA=
Thread-topic: One unstablity in fast syscall path
Recently we kept seeing intermittent domU creation failure after
VTI domain. After some debug, we found it caused by following 

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
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
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
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
community needs to think more robust solution later.


Xen-ia64-devel mailing list