Re: [poky] [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 2016-03-09 4:23 PM, Richard Purdie wrote:
> On Wed, 2016-03-09 at 13:53 -0500, Bruce Ashfield wrote:
>> On 2016-03-01 8:41 PM, Paul Gortmaker wrote:
>>> [Re: [poky] [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel] On
>>> 13/02/2016 (Sat 17:17) Richard Purdie wrote:
>>>
>>>> I'm moving the discussion to OE-Core and pulling in some kernel
>>>> people.
>>>> I think I understand what is wrong and how to fix it but I could
>>>> use
>>>> someone who actually knows this code.
>>>>
>>>> To summarise the story so far, on qemux86, X doesn't start and
>>>> there is
>>>> a backtrace in the logs:
>>>>
>>>> x86/PAT: Xorg:705 map pfn expected mapping type uncached-minus
>>>> for [mem 0xfd000000-0xfdffffff], got write-combining
>>>
>>> So Bruce helped me set up a reproducer locally today since he'd
>>> already
>>> invested the time on that, and then I boiled that down to divorce
>>> it
>>> from the slower steps of build-deploy-boot to make the bisect
>>> something
>>> that mortal humans could tolerate.
>>>
>>> Amusingly enough that led to:
>>>
>>> commit 9cd25aac1f44f269de5ecea11f7d927f37f1d01c
>>> Author: Borislav Petkov <bp@suse.de>
>>> Date:   Thu Jun 4 18:55:10 2015 +0200
>>>
>>>       x86/mm/pat: Emulate PAT when it is disabled
>>>
>>> So while some of us were joking on IRC about the validity of
>>> forcibly
>>> disabling PAT (via cmdline or Kconfig) as a workaround, the one
>>> line
>>> shortlog above tells us that it wasn't so off the mark after all.
>>>
>>> Bruce and I will decide what to do with this tomorrow, but since
>>> Richard
>>> spent so much time on it, I thought he'd like to know this in the
>>> interim.  Good times.   :-/
>>
>> As another follow up. The thread can be summarized as "It doesn't
>> look like it should have worked before, and qemu's pat emulation
>> may be the issue'.
>>
>> The suggestion is to run with 'nopat', which is what Richard
>> originally
>> did.
>>
>> So I'm going to prep a patch that drops the kernel patch, and leaves
>> nopat enabled on the qemu command line. That should get us put back
>> together in a semi-permanent way.
>
> How sure are we this is a bug in QEMU's pat emulation? If that is the
> case we should file a bug against qemu and try and fix it rather than
> work around it...

It could still be something that the kernel can work around, Toshi
did say:

There is a matter of how qemu emulates CPU features.  There is no such
Intel CPU that supports PAT w/o MTRR.  This is why the current code
assumes this dependency.

Which is likely the trigger, we've send information about the cpu to
him, and with that there's a chance for a pat fix.

He repeated our thought of running with 'nopat' while a fix is
considered.

It may be some time before that happens, and I was going to test
with the kernel patch dropped, and nopat in the qemu boot args. If
that works, I'd rather run with that, and then revisit when (if)
there's more changes upstream.

Bruce

>
> Cheers,
>
> Richard
>