Re: [PATCH v2 3/5] KVM: x86: Add support for VMware guest specific hypercalls

From: Sean Christopherson
Date: Wed Jul 23 2025 - 14:14:48 EST


On Tue, Apr 22, 2025, Zack Rusin wrote:
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 9e3be87fc82b..f817601924bd 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -183,11 +183,13 @@ config KVM_VMWARE
> depends on KVM
> default y
> help
> - Provides KVM support for hosting VMware guests. Adds support for
> - VMware legacy backdoor interface: VMware tools and various userspace
> + Provides KVM support for hosting VMware guests. KVM features that can
> + be turned on when this option is enabled include:
> + - VMware legacy backdoor interface: VMware tools and various userspace
> utilities running in VMware guests sometimes utilize specially
> formatted IN, OUT and RDPMC instructions which need to be
> intercepted.
> + - VMware hypercall interface: VMware hypercalls exit to userspace

Eh, I wouldn't bother enumerating the full set of features in the Kconfig. Just
state that it guards VMware emulation, and let the documentation do the heavy
lifting.

> +static inline bool kvm_vmware_hypercall_enabled(struct kvm *kvm)
> +{
> + return false;
> +}
> +
> +static inline int kvm_vmware_hypercall(struct kvm_vcpu *vcpu)
> +{
> + return 0;
> +}

If we do this right, we shouldn't need a stub for kvm_vmware_hypercall(), and
can instead uncondtionally _declare_ kvm_vmware_hypercall(), but only fully
define/implement it CONFIG_KVM_VMWARE=y. The kvm_is_vmware_xxx() stubs will
probably need to be __always_inline, but otherwise things should Just Work.

So long as kvm_is_vmware_hypercall_enabled() can be resolved to a compile-time
constant (of %false), the compiler's dead-code optimization will drop the call
to kvm_vmware_hypercall() before linking. KVM (and the kernel at-large) already
heavily relies on dead-code optimization, e.g. we use this trick for sev.c APIs.

In addition to avoiding a stub, if we screw up, e.g. add an unguarded function
call, the bug will manifest as a link-time error, not a run-time error.

> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 793d0cf7ae3c..adf1a1449c06 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -135,6 +135,27 @@ struct kvm_xen_exit {
> } u;
> };
>
> +struct kvm_vmware_exit {
> +#define KVM_EXIT_VMWARE_HCALL 1
> + __u32 type;
> + __u32 pad1;
> + union {
> + struct {
> + __u32 longmode;
> + __u32 cpl;
> + __u64 rax, rbx, rcx, rdx, rsi, rdi, rbp;
> + __u64 result;
> + struct {
> + __u32 inject;
> + __u32 pad2;
> + __u32 vector;
> + __u32 error_code;
> + __u64 address;
> + } exception;
> + } hcall;
> + };
> +};

Put this in the x86 header, arch/x86/include/uapi/asm/kvm.h. The capability
itself goes in the arch-neutral header so that KVM doesn't have to worry about
collisions between capability numbers, but any arch specific payloads should go
in the arch header(s).