RE: [Xen-devel] XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 4.0.1-rc7-pre (cs/ 23029)

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

Konrad,

I believe sharept=0 is the default.  If it is set to sharept=1, the code is 
enabled only on the systems that has compatible EPT and VT-d page table format. 
 There is no such hardware on the market yet.

What type of NHM SDP do you have?  Is it a HEDT (High End Desktop) with a 
add-on graphics card?  I have been using a Westmere EP system (NHM architecture 
generation) and have not seen this problem.  I also have ready access to 
Ironlake SDP's I can test on if you see the same problem on Ironlake (i.e. core 
i5) systems.

Do you see the same problem if you do iommu=0 in the grub?

Allen

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] 
Sent: Sunday, March 20, 2011 1:38 PM
To: Keir Fraser; Kay, Allen M; Tim.Deegan@xxxxxxxxxx
Cc: Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 
4.0.1-rc7-pre (cs/ 23029)

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
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=DX58SO

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel