From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: unconditional CPUID propagation? Date: Thu, 4 Aug 2011 11:07:29 -0300 Message-ID: <20110804140729.GA16312@amt.cnet> References: <4E3917D6.6030905@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Anthony Liguori , KVM list , Alexander Graf To: Andre Przywara Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17388 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751049Ab1HDOK1 (ORCPT ); Thu, 4 Aug 2011 10:10:27 -0400 Content-Disposition: inline In-Reply-To: <4E3917D6.6030905@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Aug 03, 2011 at 11:41:42AM +0200, Andre Przywara wrote: > Hi, > > while looking through the code I found commit > f79116867ec80ed5d1d10043a3fd9ac8afd182c1 (upstream QEMU: enable > SMEP) which unconditionally propagates the bits from CPUID leaf 0x7 > to the guest. Though there is the KVM module in the line, this > currently whitelists three feature bits. > Doesn't that break migration? The result of the CPUID instruction > the guess issues only depends on the host and the KVM module's > policy, not on the CPU model QEMU uses. So I guess migrating from a > newer CPU to an older one breaks despite a rather conservative CPU > model has been chosen intentionally by the user. > The same is probably true for the VIA CPUID leaf. > > Is that considered OK now or is that a bug? Shall the new feature > bits be made known to QEMU like the other ones on only enabled > explicitly (+smep) or by -cpu host? > I can make a patch for that if that is the right way to address this. Or if the CPU type supports it, yes.