From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754151AbdCOUOD (ORCPT ); Wed, 15 Mar 2017 16:14:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60100 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753248AbdCOUN7 (ORCPT ); Wed, 15 Mar 2017 16:13:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 491C281245 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 491C281245 Date: Wed, 15 Mar 2017 21:13:49 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, "Gabriel L. Somlo" , Paolo Bonzini , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Joerg Roedel , kvm@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4] kvm: better MWAIT emulation for guests Message-ID: <20170315201348.GA14076@potion> References: <1489605443-21045-1-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489605443-21045-1-git-send-email-mst@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 15 Mar 2017 20:13:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-03-15 21:28+0200, Michael S. Tsirkin: > Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem: > unless explicitly provided with kernel command line argument > "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability, > without checking CPUID. > > We currently emulate that as a NOP but on VMX we can do better: let > guest stop the CPU until timer, IPI or memory change. CPU will be busy > but that isn't any worse than a NOP emulation. > > Note that mwait within guests is not the same as on real hardware > because halt causes an exit while mwait doesn't. For this reason it > might not be a good idea to use the regular MWAIT flag in CPUID to > signal this capability. Add a flag in the hypervisor leaf instead. > > Additionally, we add a capability for QEMU - e.g. if it knows there's an > isolated CPU dedicated for the VCPU it can set the standard MWAIT flag > to improve guest behaviour. > > Reported-by: "Gabriel L. Somlo" > Signed-off-by: Michael S. Tsirkin > --- > > Note: SVM bits are untested at this point. Seems pretty > obvious though. > > changes from v3: > - don't enable capability if cli+mwait blocks interrupts > - doc typo fixes (drop drop ppc doc) > > changes from v2: > - add a capability to allow host userspace to detect new kernels > - more documentation to clarify the semantics of the feature flag > and why it's useful > - svm support as suggested by Radim > > changes from v1: > - typo fix resulting in rest of leaf flags being overwritten > Reported by: Wanpeng Li > - updated commit log with data about guests helped by this feature > - better document differences between mwait and halt for guests > > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > @@ -212,4 +213,28 @@ static inline u64 nsec_to_cycles(struct kvm_vcpu *vcpu, u64 nsec) > __rem; \ > }) > > +static bool kvm_mwait_in_guest(void) > +{ > + unsigned int eax, ebx, ecx; > + > + if (!cpu_has(&boot_cpu_data, X86_FEATURE_MWAIT)) > + return -ENODEV; > + > + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) > + return -ENODEV; > + > + /* > + * 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 -ENODEV; > + > + cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates); > + > + if (!(ecx & CPUID5_ECX_INTERRUPT_BREAK)) > + return -ENODEV; The guest is still able to set ecx=0 with MWAIT, which should be the same as not having the CPUID flag, so I'm wondering how this check prevents anything harmful ... is it really a cpu "feature"? If we somehow report ecx bit 1 in CPUID[5], then the guest might try to set ecx bit 0 for MWAIT, which will cause #GP(0) and could explain the hang that Gabriel is hitting. Gabriel, - do you see VM exits on the "hung" VCPU? - what is your CPU model? - what do you get after running this C program on host and guest? #include #include int main(void) { uint32_t eax = 5, ebx, ecx = 0, edx; asm ("cpuid" : "+a"(eax), "=b"(ebx), "+c"(ecx), "=d"(edx)); printf("eax=%#08x ebx=%#08x ecx=%#08x edx=%#08x\n", eax, ebx, ecx, edx); return 0; } Thanks.