From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: unconditional CPUID propagation? Date: Wed, 3 Aug 2011 11:41:42 +0200 Message-ID: <4E3917D6.6030905@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , Alexander Graf To: Avi Kivity , Anthony Liguori Return-path: Received: from va3ehsobe006.messaging.microsoft.com ([216.32.180.16]:45421 "EHLO VA3EHSOBE009.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753565Ab1HCJpU (ORCPT ); Wed, 3 Aug 2011 05:45:20 -0400 Sender: kvm-owner@vger.kernel.org List-ID: 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. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712