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-devel] XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 4.0.1

To: Keir Fraser <keir.xen@xxxxxxxxx>, allen.m.kay@xxxxxxxxx, Tim.Deegan@xxxxxxxxxx
Subject: Re: [Xen-devel] XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 4.0.1-rc7-pre (cs/ 23029)
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Sun, 20 Mar 2011 16:37:37 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Sun, 20 Mar 2011 13:38:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9A92B54.150A3%keir.xen@xxxxxxxxx>
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>
References: <4D831E1A0200007800037343@xxxxxxxxxxxxxxxxxx> <C9A92B54.150A3%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Mar 18, 2011 at 03:31:32PM +0000, Keir Fraser wrote:
> On 18/03/2011 07:55, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> >> Exit reason 31 is EXIT_REASON_MSR_READ. I don't see how that error can ever
> >> be printed for that exit reason. Could you do a bit of digging and see if
> >> you agree? The logic is straightforward enough -- the error comes from a
> >> default case in a switch statement, but the switch does explicitly handle
> >> EXIT_REASON_MSR_READ. There is also a exit_and_crash label for the default
> >> case, but EXIT_REASON_MSR_READ doesn't goto it afaics. So this is a weird
> >> and inexplicable bug, to me. :-)
> > 
> > No, the reason is printed in hex
> Grrr! I'll add the '0x' prefix.
>  -- Keir
> > and thus it's EXIT_REASON_EPT_MISCONFIG,
> > which isn't being handled in the switch statement (and I can't see
> > how it sensibly could be). But the mere register state is insufficient
> > to determine what's wrong.

I am CC-ing Intel folks here, as hg bisection got me close to this c/s

22545:764e95f64b28 EPT/VT-d page table sharing

(It is a bit hard to narrow down the specific one, as there seems to a rash
of hotplug scripts failure in that area of hg commits).

My question is have other people have been testing machines with Intel VT-d?
I suppose this is 2nd generation VT-d, so it might require some more newer
ones. This specific hardware is

Ian, does your test-suite include this Intel DX58SO type-ish hardware?

And sure enough - the machine is an Intel SDP, and I can't seem to be able to
update the BIOS. Right now it tells me it has:

 /DX58SO, BIOS SOX5810J.86A.1171.2008.0717.0926 07/17/2008

So I am going to blame it on the hardware.

However, I noticed that I should be able to turn this patch by doing:
'sharept=0' flag but that actually does not seem to turn this functionality off.
So maybe the hardware is OK?

Xen-devel mailing list