diff mbox series

[V4,4/4] KVM: selftests: x86: Invoke kvm hypercall as per host cpu

Message ID 20221228192438.2835203-5-vannapurve@google.com
State New
Headers
Series Execute hypercalls according to host cpu |

Commit Message

Vishal Annapurve Dec. 28, 2022, 7:24 p.m. UTC 
  Invoke vmcall/vmmcall instructions from kvm_hypercall as per host CPU
type. CVMs and current kvm_hyerpcall callers need to execute hypercall
as per the cpu type to avoid KVM having to emulate the instruction
anyways.

CVMs need to avoid KVM emulation as the guest code is not updatable
from KVM. Guest code region can be marked un-mondifiable from KVM
without CVMs as well, so in general it's safer to avoid KVM emulation
for vmcall/vmmcall instructions.

Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Vishal Annapurve <vannapurve@google.com>
---
 tools/testing/selftests/kvm/lib/x86_64/processor.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Sean Christopherson Jan. 9, 2023, 6:20 p.m. UTC | #1 
KVM: selftests: Use host's native hypercall instruction in kvm_hypercall()

On Wed, Dec 28, 2022, Vishal Annapurve wrote:
> Invoke vmcall/vmmcall instructions from kvm_hypercall as per host CPU

() for functions, i.e. kvm_hypercall().

> type.

s/type/vendor, "type" is too generic.

> CVMs and current kvm_hyerpcall callers need to execute hypercall

CVM isn't a not ubiquitous acronym.  I would avoid it entirely because "CVM"
doesn't strictly imply memory encryption, e.g. KVM could still patch the guest in
a pKVM-like implementation.

  Use the host CPU's native hypercall instruction, i.e. VMCALL vs. VMMCALL,
  in kvm_hypercall(), as relying on KVM to patch in the native hypercall on
  a #UD for the "wrong" hypercall requires KVM_X86_QUIRK_FIX_HYPERCALL_INSN
  to be enabled and flat out doesn't work if guest memory is encrypted with
  a private key, e.g. for SEV VMs.
Vishal Annapurve Jan. 11, 2023, 12:18 a.m. UTC | #2 
On Mon, Jan 9, 2023 at 10:21 AM Sean Christopherson <seanjc@google.com> wrote:
>
> KVM: selftests: Use host's native hypercall instruction in kvm_hypercall()
>
> On Wed, Dec 28, 2022, Vishal Annapurve wrote:
> > Invoke vmcall/vmmcall instructions from kvm_hypercall as per host CPU
>
> () for functions, i.e. kvm_hypercall().
>
> > type.
>
> s/type/vendor, "type" is too generic.
>
> > CVMs and current kvm_hyerpcall callers need to execute hypercall
>
> CVM isn't a not ubiquitous acronym.  I would avoid it entirely because "CVM"
> doesn't strictly imply memory encryption, e.g. KVM could still patch the guest in
> a pKVM-like implementation.
>
>   Use the host CPU's native hypercall instruction, i.e. VMCALL vs. VMMCALL,
>   in kvm_hypercall(), as relying on KVM to patch in the native hypercall on
>   a #UD for the "wrong" hypercall requires KVM_X86_QUIRK_FIX_HYPERCALL_INSN
>   to be enabled and flat out doesn't work if guest memory is encrypted with
>   a private key, e.g. for SEV VMs.

Ack, this makes sense.
diff mbox series

Patch

diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c
index 18f0608743d1..cc0b9c17fa91 100644
--- a/tools/testing/selftests/kvm/lib/x86_64/processor.c
+++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c
@@ -1154,9 +1154,15 @@  uint64_t kvm_hypercall(uint64_t nr, uint64_t a0, uint64_t a1, uint64_t a2,
 {
 	uint64_t r;
 
-	asm volatile("vmcall"
+	asm volatile("test %[use_vmmcall], %[use_vmmcall]\n\t"
+		     "jnz 1f\n\t"
+		     "vmcall\n\t"
+		     "jmp 2f\n\t"
+		     "1: vmmcall\n\t"
+		     "2:"
 		     : "=a"(r)
-		     : "a"(nr), "b"(a0), "c"(a1), "d"(a2), "S"(a3));
+		     : "a"(nr), "b"(a0), "c"(a1), "d"(a2), "S"(a3),
+		       [use_vmmcall] "r" (is_host_cpu_amd()));
 	return r;
 }