ijc at hellion
Oct 11, 2011, 1:43 AM
Post #15 of 16
On Tue, 2011-10-11 at 09:36 +0100, Jan Beulich wrote:
Re: Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
[In reply to]
> >>> On 11.10.11 at 10:02, Ian Campbell <ijc [at] hellion> wrote:
> > On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote:
> >> >>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >> > On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote:
> >> >> OK, I tried it again, but Oops didn't gone.
> >> > .. snip..
> >> >> echo 'Loading Xen 4.0-amd64 ...'
> >> >> multiboot /boot/xen-4.0-amd64.gz placeholder xsave=0
> >> > .. snip..
> >> >> Was it right?
> >> >
> >> > Yup. I think.. this is a bit embarrassing. It took a bit of time for Intel
> >> > folks to get the xsave part right and I remember seeing this error about a
> >> > year ago with xsave on a Dell Optiplex 780. Hence I wonder if the fixes
> > that
> >> > ultimately went in 4.1.1 did not get ported over to 4.0 and you are just
> >> > hitting that.
> >> >
> >> > Can I ask you to do one more thing? Can you upgrade to the xen-4.1.1 in
> >> > the testing and try with the xsave (or without) and see if it works?
> >> >
> >> > <holds his fingers hoping it is the xsave feature>
> >> Are both of you certain this isn't the problem of the kernel only
> >> looking at the xsaveopt feature flag (implying that this means
> >> xsave is also available)? I found it necessary to force-clear that
> >> flag in the kernel when OSXSAVE is not set (by calling
> >> x86_xsave_setup() when !cpu_has_xsave, which in turn was
> >> modified to look at X86_FEATURE_OSXSAVE rather than
> >> X86_FEATURE_XSAVE under Xen - all of which I'm afraid would
> >> need to be done differently in pv-ops).
> > That all sounds familiar... In mainline we have (in
> > xen_init_cpuid_mask):
> > ...
> > xsave_mask =
> > (1 << (X86_FEATURE_XSAVE % 32)) |
> > (1 << (X86_FEATURE_OSXSAVE % 32));
> > /* Xen will set CR4.OSXSAVE if supported and not disabled by force
> > */
> > if ((cx & xsave_mask) != xsave_mask)
> > cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE &
> > OSXSAVE */
> > Which I think implements something similar to what you describe? IOW
> > unless both XSAVE and OSXSAVE are available both are forcibly disabled.
> Apart from the need to disable XSAVEOPT, yes.
Oh, right, I hadn't noticed it was a different/third flag.
> > While grepping I noticed that the kernel command line parameter to
> > disable xsave appears to be "noxsave" rather than "xsave=0", Rush is
> > that something you could try? (GRUB_CMDLINE_LINUX is the place to add
> > it)
> Or "noxsaveopt" (if that's the problem, i.e. Rush's CPUs have that
Right, Rush can you try both "noxsave" and "noxsaveopt" independently
please. If those work then we need to update the above logic to mask
xsaveopt as well.
> > Ian.
> >> If it is, the problem could be worked around by *en*abling xsave
> >> in Xen (which is off by default prior to 4.2), assuming none of the
> >> incomplete functionality would cause other headaches.
> >> But yes, the CPUID handling code in 4.1.1 should properly hide
> >> XSAVEOPT when XSAVE is disabled, so just using this version
> >> ought to also get things going.
> >> Jan
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel [at] lists
> >> http://lists.xensource.com/xen-devel
> > --
> > Ian Campbell
> > Current Noise: Zyklon - Hammer Revelation
> > The ultimate game show will be the one where somebody gets killed at the
> > end.
> > -- Chuck Barris, creator of "The Gong Show"
> Xen-devel mailing list
> Xen-devel [at] lists
Current Noise: Zyklon - Transcendental War - Battle Between Gods
If you tell the truth you don't have to remember anything.
-- Mark Twain
Xen-devel mailing list
Xen-devel [at] lists