linux-kernel - Re: [PATCH] x86, kvm, vmx: Always use LOAD_IA32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141110043350.GA3773@kernel>
Date:	Mon, 10 Nov 2014 12:33:50 +0800
From:	Wanpeng Li <wanpeng.li@...ux.intel.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Paolo Bonzini <pbonzini@...hat.com>,
	Gleb Natapov <gleb@...nel.org>
Subject: Re: [PATCH] x86, kvm, vmx: Always use LOAD_IA32_EFER if available

Hi Andy,
On Fri, Nov 07, 2014 at 06:25:18PM -0800, Andy Lutomirski wrote:
>At least on Sandy Bridge, letting the CPU switch IA32_EFER is much
>faster than switching it manually.
>
>I benchmarked this using the vmexit kvm-unit-test (single run, but
>GOAL multiplied by 5 to do more iterations):
>
>Test                                  Before      After    Change
>cpuid                                   2000       1932    -3.40%
>vmcall                                  1914       1817    -5.07%
>mov_from_cr8                              13         13     0.00%
>mov_to_cr8                                19         19     0.00%
>inl_from_pmtimer                       19164      10619   -44.59%
>inl_from_qemu                          15662      10302   -34.22%

What's the difference of IA32_EFER between guest and host in your config?

IIUC,
- NX is not consistent
  IA32_EFER will be auto load w/ and w/o the patch.
- SCE is not consistent 
  IA32_EFER will be switched through wrmsr(urn) w/o the patch, and auto load
  w/ the patch.

Regards,
Wanpeng Li 

>inl_from_kernel                         3916       3802    -2.91%
>outl_to_kernel                          2230       2194    -1.61%
>mov_dr                                   172        176     2.33%
>ipi                                (skipped)  (skipped)
>ipi+halt                           (skipped)  (skipped)
>ple-round-robin                           13         13     0.00%
>wr_tsc_adjust_msr                       1920       1845    -3.91%
>rd_tsc_adjust_msr                       1892       1814    -4.12%
>mmio-no-eventfd:pci-mem                16394      11165   -31.90%
>mmio-wildcard-eventfd:pci-mem           4607       4645     0.82%
>mmio-datamatch-eventfd:pci-mem          4601       4610     0.20%
>portio-no-eventfd:pci-io               11507       7942   -30.98%
>portio-wildcard-eventfd:pci-io          2239       2225    -0.63%
>portio-datamatch-eventfd:pci-io         2250       2234    -0.71%
>
>I haven't explicitly computed the significance of these numbers,
>but this isn't subtle.
>
>Signed-off-by: Andy Lutomirski <luto@...capital.net>
>---
> arch/x86/kvm/vmx.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>index 3e556c68351b..e72b9660e51c 100644
>--- a/arch/x86/kvm/vmx.c
>+++ b/arch/x86/kvm/vmx.c
>@@ -1659,8 +1659,14 @@ static bool update_transition_efer(struct vcpu_vmx *vmx, int efer_offset)
> 	vmx->guest_msrs[efer_offset].mask = ~ignore_bits;
> 
> 	clear_atomic_switch_msr(vmx, MSR_EFER);
>-	/* On ept, can't emulate nx, and must switch nx atomically */
>-	if (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX)) {
>+
>+	/*
>+	 * On EPT, we can't emulate NX, so we must switch EFER atomically.
>+	 * On CPUs that support "load IA32_EFER", always switch EFER
>+	 * atomically, since it's faster than switching it manually.
>+	 */
>+	if (cpu_has_load_ia32_efer ||
>+	    (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) {
> 		guest_efer = vmx->vcpu.arch.efer;
> 		if (!(guest_efer & EFER_LMA))
> 			guest_efer &= ~EFER_LME;
>-- 
>1.9.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe kvm" in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/