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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.