From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>,
allen.m.kay@intel.com, Tim.Deegan@citrix.com
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@novell.com>
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 [thread overview]
Message-ID: <20110320203737.GC3447@dumpdata.com> (raw)
In-Reply-To: <C9A92B54.150A3%keir.xen@gmail.com>
On Fri, Mar 18, 2011 at 03:31:32PM +0000, Keir Fraser wrote:
> On 18/03/2011 07:55, "Jan Beulich" <JBeulich@novell.com> 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?
next prev parent reply other threads:[~2011-03-20 20:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 20:26 XEN) vmx.c:2652:d1 Bad vmexit (reason 31) with Xen 4.0.1-rc7-pre (cs/ 23029) Konrad Rzeszutek Wilk
2011-03-17 20:34 ` Konrad Rzeszutek Wilk
2011-03-17 23:27 ` Keir Fraser
2011-03-18 0:10 ` Konrad Rzeszutek Wilk
2011-03-18 0:47 ` Konrad Rzeszutek Wilk
2011-03-18 7:55 ` Jan Beulich
2011-03-18 15:31 ` Keir Fraser
2011-03-20 20:37 ` Konrad Rzeszutek Wilk [this message]
2011-03-20 22:43 ` Kay, Allen M
2011-03-21 11:35 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110320203737.GC3447@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@novell.com \
--cc=Tim.Deegan@citrix.com \
--cc=allen.m.kay@intel.com \
--cc=keir.xen@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).