Re: [PATCH] kvm/vmx: EPTP switching test
Date: Mon Nov 16 2015 - 12:51:17 EST
2015-11-15 18:00+0200, Michael S. Tsirkin:
> This patch adds a new parameter: eptp_switching_test, which enables
> testing EPT switching on VMX if supported by hardware. All EPT entries
> are initialized to the same value so this adds no useful functionality
> by itself, but can be used to test VMFUNC performance, and serve as a
> basis for future features based on EPTP switching.
> Support for nested virt is not enabled.
> This was tested using the following code within guest:
> #define VMX_VMFUNC ".byte 0x0f,0x01,0xd4"
> static void vmfunc(unsigned int nr, unsigned int ept)
> asm volatile(VMX_VMFUNC
> : "a"(nr), "c"(ept)
> : "memory");
> VMFUNC instruction cost was measured at ~122 cycles.
> (Note: recent versions of gnu toolchain support
> the vmfunc instruction - removing the need for writing
> the bytecode manually).
> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> I think I'd like to put this upstream so future eptp switching work can
> be implemented on top. Comments?
I'd wait for the future. Patch is already on the list so people
interested in benchmarking VMFUNC can quickly compile a kernel and
developers will need to overwrite the code anyway.
(And I think that eptp switching is expected to be used in conjuction
with #VE, so it'd then make sense to implement a nop for it as well.)
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> @@ -3011,6 +3035,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
> SECONDARY_EXEC_PAUSE_LOOP_EXITING |
> SECONDARY_EXEC_RDTSCP |
> SECONDARY_EXEC_ENABLE_INVPCID |
> + SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
The VMFUNC vmexit should be handled to prevent guests from triggering a
WARN_ON on the host. (VMFUNC did just #UD before this patch.)
After that, it's ok for KVM.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/