From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 4.0.1-rc7-pre (cs/ 23029) Date: Sun, 20 Mar 2011 16:37:37 -0400 Message-ID: <20110320203737.GC3447@dumpdata.com> References: <4D831E1A0200007800037343@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , allen.m.kay@intel.com, Tim.Deegan@citrix.com Cc: xen-devel@lists.xensource.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Fri, Mar 18, 2011 at 03:31:32PM +0000, Keir Fraser wrote: > On 18/03/2011 07:55, "Jan Beulich" 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?