From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751763AbdCNN6j (ORCPT ); Tue, 14 Mar 2017 09:58:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59099 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbdCNN63 (ORCPT ); Tue, 14 Mar 2017 09:58:29 -0400 Date: Tue, 14 Mar 2017 14:58:24 +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 v3] kvm: better MWAIT emulation for guests Message-ID: <20170314135823.GA5432@potion> References: <1489448438-29865-1-git-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489448438-29865-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.30]); Tue, 14 Mar 2017 13:58:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-03-14 01:44+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 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/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > @@ -4135,11 +4135,11 @@ available, means that that the kernel can support guests using the > radix MMU defined in Power ISA V3.00 (as implemented in the POWER9 > processor). > > -8.4 KVM_CAP_PPC_HASH_MMU_V3 This patch should not not remove the PPC capability from docs. (The right name is KVM_CAP_PPC_HASH_V3, but that is for another patch.) > +8.5 KVM_CAP_X86_GUEST_MWAIT > > -Architectures: ppc > +Architectures: x86 > > -This capability, if KVM_CHECK_EXTENSION indicates that it is > -available, means that that the kernel can support guests using the > -hashed page table MMU defined in Power ISA V3.00 (as implemented in > -the POWER9 processor), including in-memory segment tables. > +This capability indicates that guest using memory monotoring instructions > +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit. As such time > +spent while virtual CPU is halted in this way will then be accounted for as > +guest running time on the host (as opposed to e.g. HLT). > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > @@ -2684,6 +2684,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ADJUST_CLOCK: > r = KVM_CLOCK_TSC_STABLE; > break; > + case KVM_CAP_X86_GUEST_MWAIT: > + r = !!this_cpu_has(X86_FEATURE_MWAIT); this_cpu_has already returns bool, so !! is not needed. I can fix both while applying. > + break; > case KVM_CAP_X86_SMM: > /* SMBASE is usually relocated above 1M on modern chipsets, > * and SMM handlers might indeed rely on 4G segment limits,