Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)

Marcelo Tosatti
2010-12-02T17:52:42Z

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 <aliguori@us.ibm.com>
> ---
> 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"), timer reinjection
probably. It should be possible to achieve determinism with
a scheduler policy?