From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752823AbdEDK6W (ORCPT ); Thu, 4 May 2017 06:58:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59798 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbdEDK6K (ORCPT ); Thu, 4 May 2017 06:58:10 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D200180F7C Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D200180F7C Subject: Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20170503193733.13409-1-rkrcmar@redhat.com> <20170503193733.13409-4-rkrcmar@redhat.com> Cc: Alexander Graf , "Michael S. Tsirkin" , "Gabriel L. Somlo" From: Paolo Bonzini Message-ID: <638dd02c-102a-21d8-7a10-30a3ef3c357d@redhat.com> Date: Thu, 4 May 2017 12:58:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170503193733.13409-4-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 04 May 2017 10:58:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/05/2017 21:37, Radim Krčmář wrote: > The guest can call MWAIT with ECX = 0 even if we enforce > CPUID5_ECX_INTERRUPT_BREAK; the call would have the exactly the same > effect as if the host didn't have CPUID5_ECX_INTERRUPT_BREAK. > > The check was added in some iteration while trying to fix a reported > OS X on Core 2 bug, but the CPU had CPUID5_ECX_INTERRUPT_BREAK and the > bug is elsewhere. The reason for this, as I understood it, is that we have historically not published leaf 5 information via KVM_GET_SUPPORTED_CPUID. For this reason, QEMU is publishing CPUID5_ECX_INTERRUPT_BREAK. Then if: - the host doesn't have ECX[0]=1 support - the guest sets ECX[0] you get a #GP in the guest. So wrong comment but right thing to do. Paolo > Signed-off-by: Radim Krčmář > --- > arch/x86/kvm/x86.h | 23 +---------------------- > 1 file changed, 1 insertion(+), 22 deletions(-) > > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > index 63d5fb65ea30..8ea4e80c24d1 100644 > --- a/arch/x86/kvm/x86.h > +++ b/arch/x86/kvm/x86.h > @@ -216,8 +216,6 @@ static inline u64 nsec_to_cycles(struct kvm_vcpu *vcpu, u64 nsec) > > static inline bool kvm_mwait_in_guest(void) > { > - unsigned int eax, ebx, ecx, edx; > - > if (!cpu_has(&boot_cpu_data, X86_FEATURE_MWAIT)) > return false; > > @@ -225,29 +223,10 @@ static inline bool kvm_mwait_in_guest(void) > case X86_VENDOR_AMD: > return !boot_cpu_has_bug(X86_BUG_AMD_E400); > case X86_VENDOR_INTEL: > - /* Handle Intel below */ > - break; > + return !boot_cpu_has_bug(X86_BUG_MONITOR); > default: > return false; > } > - > - if (boot_cpu_has_bug(X86_BUG_MONITOR)) > - return false; > - > - /* > - * Intel CPUs without CPUID5_ECX_INTERRUPT_BREAK are problematic as > - * they would allow guest to stop the CPU completely by disabling > - * interrupts then invoking MWAIT. > - */ > - if (boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF) > - return false; > - > - cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx); > - > - if (!(ecx & CPUID5_ECX_INTERRUPT_BREAK)) > - return false; > - > - return true; > } > > #endif >