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
|