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-devel] Grant table corruption with HVM guest

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Grant table corruption with HVM guest
From: "Justin T. Gibbs" <gibbs@xxxxxxxxxxx>
Date: Sun, 14 Mar 2010 13:10:38 -0600
Delivery-date: Sun, 14 Mar 2010 12:11:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv: Gecko/20100204 Thunderbird/3.0.1
I'm experiencing total grant table corruption on a system and I'm
hoping my symptoms will ring a bell with a member of the Xen developer
community.  The setup is Xen 4.0.0-RC2 (OpenSUSE 11.2 package) on
a Nehalem system.  The sole guest instance is 64bit FreeBSD running
in HVM mode, a single vcpu, and a PCI passed-through LSI Logic 1068e
SAS controller.  FreeBSD is running netfront and blockfront PV
drivers.  After a few hours of operation, FreeBSD's entire grant
table (3 pages) is spammed with the pattern 0x5a5a5a5a.  This problem
has been replicated on multiple machines.

The first assumption was a bug in the FreeBSD PV drivers or other Xen
support.  To rule this out, we modified FreeBSD's grant table functions
to unmap the grant table from the kernel virtual address space between
operations.  This was on a single vcpu setup, but to rule out corruption
by interrupt handlers, interrupts were also disabled while the mapping was
valid during grant table updates.  The corruption still occurs without the
FreeBSD kernel faulting on unmapped pages.  I believe this leaves a VT-D
HW problem or a bug in the hypervisor as the remaining possibilities.
I'm working now to further isolate the error by changing our test load
so I can remove VT-D from the configuration.

Are there any Xen or QEMU components that use a 0x5a5a5a5a initialization
pattern?  Are there any tools in the hypervisor I can use to trap rogue
access to guest grant table pages?


Xen-devel mailing list

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