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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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?

Cheers,

Richard