[OE-core] [poky] [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel

Bruce Ashfield bruce.ashfield at windriver.com
Thu Mar 10 21:55:52 UTC 2016


On 2016-03-10 3:59 PM, Richard Purdie wrote:
> On Wed, 2016-03-09 at 23:12 -0500, Bruce Ashfield wrote:
>> On 2016-03-09 4:23 PM, Richard Purdie wrote:
>>> On Wed, 2016-03-09 at 13:53 -0500, Bruce Ashfield wrote:
>>>> 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.
>
> Reading the other thread, it looks like if MTRR is disabled, PAT needs
> to be disabled too. That sounds like a simple enough patch which is
> going upstream imminently so I think the preferred solution is to get
> that into our kernels and then drop my patch?

Yep. Looks like there's a patch to disable the pat based on the flags
of the cpu model being proposed.

When that's out, I'll merge it, and then we'll drop this. So for now,
we wait a bit longer.

Bruce

>
> Cheers,
>
> Richard
>




More information about the Openembedded-core mailing list