Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752835AbcCKXm7 (ORCPT ); Fri, 11 Mar 2016 18:42:59 -0500 Received: from 5751f4a1.skybroadband.com ([87.81.244.161]:51749 "EHLO dan.rpsys.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751562AbcCKXm5 (ORCPT ); Fri, 11 Mar 2016 18:42:57 -0500 X-Greylist: delayed 735 seconds by postgrey-1.27 at vger.kernel.org; Fri, 11 Mar 2016 18:42:56 EST Message-ID: <1457738994.2804.266.camel@linuxfoundation.org> Subject: Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled" From: Richard Purdie To: Bruce Ashfield , Borislav Petkov , Paolo Bonzini Cc: One Thousand Gnomes , Paul Gortmaker , Toshi Kani , Toshi Kani , "Hart, Darren" , "saul.wold" , linux-kernel@vger.kernel.org, kvm ML , x86-ml Date: Fri, 11 Mar 2016 23:29:54 +0000 In-Reply-To: <56E34695.2020300@windriver.com> References: <1457398578.15454.421.camel@hpe.com> <1457400913.15454.435.camel@hpe.com> <20160310144250.GG23251@windriver.com> <1457628591.15454.542.camel@hpe.com> <20160310172029.GA2194@pd.tnic> <20160310190429.GI23251@windriver.com> <20160310191933.GC2194@pd.tnic> <20160311132356.43a7b373@lxorguk.ukuu.org.uk> <20160311134000.GC4347@pd.tnic> <56E319FF.3090709@redhat.com> <20160311221651.GE4347@pd.tnic> <56E34695.2020300@windriver.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1798 Lines: 42 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