| Message ID | 20221228192438.2835203-5-vannapurve@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Execute hypercalls according to host cpu | expand |
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.
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 --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; }
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(-)