From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756284AbdEDS1H (ORCPT ); Thu, 4 May 2017 14:27:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755941AbdEDS0d (ORCPT ); Thu, 4 May 2017 14:26:33 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 16B0951452 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 16B0951452 Date: Thu, 4 May 2017 21:26:32 +0300 From: "Michael S. Tsirkin" To: Paolo Bonzini Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Alexander Graf , "Gabriel L. Somlo" Subject: Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check Message-ID: <20170504212458-mutt-send-email-mst@kernel.org> References: <20170503193733.13409-1-rkrcmar@redhat.com> <20170503193733.13409-4-rkrcmar@redhat.com> <638dd02c-102a-21d8-7a10-30a3ef3c357d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <638dd02c-102a-21d8-7a10-30a3ef3c357d@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 04 May 2017 18:26:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 04, 2017 at 12:58:05PM +0200, Paolo Bonzini wrote: > > > 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 Exactly. And I agree the comment isn't a good one. > > 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 > >