Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000

["Olivier B." <xen.list@daevel.fr>]

On 11/10/2011 10:43, Ian Campbell wrote:
> On Tue, 2011-10-11 at 09:36 +0100, Jan Beulich wrote:
>>>>> On 11.10.11 at 10:02, Ian Campbell<ijc@hellion.org.uk>  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@oracle.com>  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
>> capability).
>
> 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.
>
> Thanks,
> Ian.
>


For the record, same problem here with Xen 4.0 and an Intel Xeon CPU E31220 with "microcode 0x14".
(and the problem doesn't exists with a CPU E31220 without that microcode).


The xen parameter "noxsaveopt" solved it.

Olivier