Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

[Richard Purdie]

On Fri, 2016-03-11 at 17:28 -0500, Bruce Ashfield wrote:
> On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> > On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
> > > Somebody got it wrong 10-ish years ago, and nobody has ever
> > > checked since.
> > > 
> > > But, don't use qemu32 or qemu64.  Use kvm32 and kvm64, or better
> > > something like the host you run on ("-cpu Nehalem", "-cpu
> > > SandyBridge",
> > > "-cpu Haswell-noTSX" etc.).
> > 
> > Paul, Richard, how about it?
> 
> I'm not Paul/Richard, but I can answer :)
> 
> We want a more generic cpu for these qemu references. Something that
> doesn't vary, since it runs on any number of hosts. There are some
> horrible issues we've had to solve with -cpu host in the past.
> 
> Switching to the kvm cpu type should work, plus we can add cpu
> extensions on the fly as necessary.
> 
> That's definitely a valid outcome from this discussion .. a cpu
> type that doesn't shoot through the middle of the expected
> capabilities .. and a bonus if the kernel or qemu can be tweaked
> to survive a similar mix up in the flags in the future.

We'll have to go and trawl our commit logs to figure out how we ended
up with choosing qemuXX, I do remember everything else we tried
previously broke in some way. We do need something which works on quite
a wide variety of systems and if I remember rightly, the CPU features
the kvm* options provide vary quite widely and wasn't consistent. The
qemu* ones at least consistently broke everywhere! :)

Tweaking the kernel to only enable PAT with MTRR sounds like a good
fix, as does fixing the qemu cpu feature bits and I'd like to get those
patches into our builds once they're heading into the upstreams.
Meanwhile we'll see if we can find a better cpu option as well.

Cheers,

Richard