WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8

To: "Ian Campbell" <ijc@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Tue, 11 Oct 2011 09:36:56 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, rush <rush1503@xxxxxxxxx>, Jonathan Nieder <jrnieder@xxxxxxxxx>, "642154@xxxxxxxxxxxxxxx" <642154@xxxxxxxxxxxxxxx>, Ben Hutchings <ben@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 11 Oct 2011 01:37:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1318320174.21903.485.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1316524835.4122.8.camel@deadeye> <1316526058.3891.65.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110922190018.GA16678@xxxxxxxxxxxxxxxxx> <20111001025030.GA5198@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA+rvmvLkBVseDCKyfbd_mGSCrRUvov5Km_2Uoo6CZPZOG7ybvA@xxxxxxxxxxxxxx> <1317460798.11991.2.camel@xxxxxxxxxxxxxxxxxxxx> <CA+rvmv+yU0=nEuvLSqkE44RFqeaQw504MkD-sxjXV3D3nkme_g@xxxxxxxxxxxxxx> <20111003184722.GB15608@xxxxxxxxxxxxxxxxx> <1317667984.11991.6.camel@xxxxxxxxxxxxxxxxxxxx> <CA+rvmvJ_i4Ta+GV5PQ0U7+2yPxT2oJXtnE_fq0j8Faa7GcUxqw@xxxxxxxxxxxxxx> <20111010164920.GA30351@xxxxxxxxxxxxxxxxx> <4E940744020000780005A9F9@xxxxxxxxxxxxxxxxxxxx> <1318320174.21903.485.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 11.10.11 at 10:02, Ian Campbell <ijc@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> 
>> >>> 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.

> 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
capability).

Jan

> 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@xxxxxxxxxxxxxxxxxxx 
>> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel