Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750757AbdCMHo0 (ORCPT ); Mon, 13 Mar 2017 03:44:26 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35835 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbdCMHoP (ORCPT ); Mon, 13 Mar 2017 03:44:15 -0400 MIME-Version: 1.0 In-Reply-To: <20170310030712-mutt-send-email-mst@kernel.org> References: <1489098555-23856-1-git-send-email-mst@redhat.com> <20170310005126.GA19516@foober.ini.cmu.edu> <20170310030712-mutt-send-email-mst@kernel.org> From: Wanpeng Li Date: Mon, 13 Mar 2017 15:44:02 +0800 Message-ID: Subject: Re: [PATCH] kvm: better MWAIT emulation for guests To: "Michael S. Tsirkin" Cc: "Gabriel L. Somlo" , "linux-kernel@vger.kernel.org" , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "the arch/x86 maintainers" , kvm , linux-doc@vger.kernel.org, Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1814 Lines: 51 Cc Peterz, 2017-03-10 9:12 GMT+08:00 Michael S. Tsirkin : > On Thu, Mar 09, 2017 at 07:51:27PM -0500, Gabriel L. Somlo wrote: >> On Fri, Mar 10, 2017 at 12:29:31AM +0200, Michael S. Tsirkin wrote: >> > Some guests call mwait without checking the cpu flags. We currently >> > emulate that as a NOP but on VMX we can do better: let guest stop the >> > CPU until timer or IPI. CPU will be busy but that isn't any worse than >> > a NOP emulation. >> >> Are you getting an IPI if another VCPU writes to the MONITOR-ed memory >> location? > > In my testing yes. Why there is still an IPI if monitor/mwait is used in guest? > >> If not, you'd be waking up too late and fail to meet the >> specified behavior of the MONITOR/MWAIT instruction pair. >> >> > Note that mwait within guests is not the same as on real hardware >> > because you must halt if you want to go deep into sleep. Thus it isn't >> > a good idea to use the regular MWAIT flag in CPUID for that. Add a flag >> > in the hypervisor leaf instead. >> >> Is it a good idea to advertise MWAIT capability to guests? > > I think it isn't so this patch does not do it. > >> The >> misbehaving ones will call it willy-nilly, true, but aren't compliant >> ones better off falling back to some alternative method (typically >> using a HLT-based idle loop instead of a MONITOR/MWAIT based one) ? >> >> Thanks, >> --Gabriel >> [...] >> > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, >> > if (sched_info_on()) >> > entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); >> > >> > + if (this_cpu_has(X86_FEATURE_MWAIT)) >> > + entry->eax = (1 << KVM_FEATURE_MWAIT); s/"="/"|=", otherwise you almost kill other features. Regards, Wanpeng Li