From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2) Date: Thu, 02 Dec 2010 13:07:15 -0600 Message-ID: <4CF7EE63.40209@codemonkey.ws> References: <1291298357-5695-1-git-send-email-aliguori@us.ibm.com> <20101202173733.GA26342@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity , Chris Wright , Srivatsa Vaddagiri To: Marcelo Tosatti Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:54144 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756171Ab0LBTHS (ORCPT ); Thu, 2 Dec 2010 14:07:18 -0500 Received: by yxt3 with SMTP id 3so3822596yxt.19 for ; Thu, 02 Dec 2010 11:07:17 -0800 (PST) In-Reply-To: <20101202173733.GA26342@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 12/02/2010 11:37 AM, Marcelo Tosatti wrote: > On Thu, Dec 02, 2010 at 07:59:17AM -0600, Anthony Liguori wrote: > >> In certain use-cases, we want to allocate guests fixed time slices where idle >> guest cycles leave the machine idling. There are many approaches to achieve >> this but the most direct is to simply avoid trapping the HLT instruction which >> lets the guest directly execute the instruction putting the processor to sleep. >> >> Introduce this as a module-level option for kvm-vmx.ko since if you do this >> for one guest, you probably want to do it for all. A similar option is possible >> for AMD but I don't have easy access to AMD test hardware. >> >> Signed-off-by: Anthony Liguori >> --- >> v1 -> v2 >> - Rename parameter to yield_on_hlt >> - Remove __read_mostly >> >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >> index caa967e..d8310e4 100644 >> --- a/arch/x86/kvm/vmx.c >> +++ b/arch/x86/kvm/vmx.c >> @@ -69,6 +69,9 @@ module_param(emulate_invalid_guest_state, bool, S_IRUGO); >> static int __read_mostly vmm_exclusive = 1; >> module_param(vmm_exclusive, bool, S_IRUGO); >> >> +static int yield_on_hlt = 1; >> +module_param(yield_on_hlt, bool, S_IRUGO); >> + >> #define KVM_GUEST_CR0_MASK_UNRESTRICTED_GUEST \ >> (X86_CR0_WP | X86_CR0_NE | X86_CR0_NW | X86_CR0_CD) >> #define KVM_GUEST_CR0_MASK \ >> @@ -1419,7 +1422,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf) >> &_pin_based_exec_control)< 0) >> return -EIO; >> >> - min = CPU_BASED_HLT_EXITING | >> + min = >> #ifdef CONFIG_X86_64 >> CPU_BASED_CR8_LOAD_EXITING | >> CPU_BASED_CR8_STORE_EXITING | >> @@ -1432,6 +1435,10 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf) >> CPU_BASED_MWAIT_EXITING | >> CPU_BASED_MONITOR_EXITING | >> CPU_BASED_INVLPG_EXITING; >> + >> + if (yield_on_hlt) >> + min |= CPU_BASED_HLT_EXITING; >> + >> opt = CPU_BASED_TPR_SHADOW | >> CPU_BASED_USE_MSR_BITMAPS | >> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS; >> -- >> 1.7.0.4 >> > Breaks async PF (see "checks on guest state"), Sorry, I don't follow what you mean here. Can you elaborate? > timer reinjection > probably. Timer reinjection will continue to work as expected. If a guest is halting an external interrupt is delivered (by a timer), the guest will still exit as expected. I can think of anything that would be functionally correct and still depend on getting hlt exits because ultimately, a guest never actually has to do a hlt (and certainly there are guests that won't). > It should be possible to achieve determinism with > a scheduler policy? > If the desire is the ultimate desire is to have the guests be scheduled in a non-work conserving fashion, I can't see a more direct approach that to simply not have the guests yield (which is ultimately what hlt trapping does). Anything the scheduler would do is after the fact and probably based on inference about why the yield. Regards, Anthony Liguori > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >