Confidential VMs(CVMs) need to execute hypercall instruction as per the CPU
type. Normally KVM emulates the vmcall/vmmcall instruction by patching
the guest code at runtime. Such a guest memory manipulation by KVM is
not allowed with CVMs and is also undesirable in general.
This series adds support of executing hypercall as per the host cpu
type queried using cpuid instruction. CPU vendor type is stored early
during selftest setup and guest setup to be reused later.
Changes in v4:
1) Incoporated suggestions from Sean -
* Added APIs to query host cpu type
* Shared the host cpu type with guests to avoid querying the cpu type
again
* Modified kvm_hypercall to execute vmcall/vmmcall according to host
cpu type.
2) Dropped the separate API for kvm_hypercall.
v3:
https://lore.kernel.org/lkml/[email protected]/
Vishal Annapurve (4):
KVM: selftests: x86: use this_cpu_* helpers
KVM: selftests: x86: Add variables to store cpu type
KVM: sefltests: x86: Replace is_*cpu with is_host_*cpu
KVM: selftests: x86: Invoke kvm hypercall as per host cpu
.../selftests/kvm/include/x86_64/processor.h | 26 ++++++++++-
.../selftests/kvm/lib/x86_64/processor.c | 44 ++++++++++---------
.../selftests/kvm/x86_64/fix_hypercall_test.c | 4 +-
.../selftests/kvm/x86_64/mmio_warning_test.c | 2 +-
.../kvm/x86_64/pmu_event_filter_test.c | 4 +-
.../vmx_exception_with_invalid_guest_state.c | 2 +-
6 files changed, 54 insertions(+), 28 deletions(-)
--
2.39.0.314.g84b9a713c41-goog
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 <[email protected]>
Signed-off-by: Vishal Annapurve <[email protected]>
---
tools/testing/selftests/kvm/lib/x86_64/processor.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
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;
}
--
2.39.0.314.g84b9a713c41-goog
On Wed, Dec 28, 2022 at 07:24:34PM +0000, Vishal Annapurve wrote:
> Confidential VMs(CVMs) need to execute hypercall instruction as per the CPU
> type. Normally KVM emulates the vmcall/vmmcall instruction by patching
> the guest code at runtime. Such a guest memory manipulation by KVM is
> not allowed with CVMs and is also undesirable in general.
>
> This series adds support of executing hypercall as per the host cpu
> type queried using cpuid instruction. CPU vendor type is stored early
> during selftest setup and guest setup to be reused later.
>
> Changes in v4:
> 1) Incoporated suggestions from Sean -
> * Added APIs to query host cpu type
> * Shared the host cpu type with guests to avoid querying the cpu type
> again
> * Modified kvm_hypercall to execute vmcall/vmmcall according to host
> cpu type.
> 2) Dropped the separate API for kvm_hypercall.
>
> v3:
> https://lore.kernel.org/lkml/[email protected]/
>
> Vishal Annapurve (4):
> KVM: selftests: x86: use this_cpu_* helpers
> KVM: selftests: x86: Add variables to store cpu type
> KVM: sefltests: x86: Replace is_*cpu with is_host_*cpu
> KVM: selftests: x86: Invoke kvm hypercall as per host cpu
For the series,
Reviewed-by: David Matlack <[email protected]>
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 <[email protected]> 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.