Re: [PATCH v3 06/12] KVM: x86: Forward VMware hypercalls to userspace

[David Woodhouse]

On Wed, 2026-11-11 at 00:59 -0500, Zack Rusin wrote:
> 
> +		/* KVM_EXIT_VMWARE */
> +		struct kvm_vmware_exit {
> +			__u32 type;
> +			__u32 pad1;
> +			union {
> +				struct {
> +					__u32 longmode;
> +					__u32 cpl;
> +					struct {
> +						__u32 inject;
> +						__u32 pad2;
> +						__u32 vector;
> +						__u32 error_code;
> +						__u64 address;

Perhaps add a few words more padding here?

> +					} exception;
> +				} hcall;
> +			};
> +		} vmware;
> 
...
> +Userspace may instead set ``exception.inject`` to one and request #UD, #GP,
> +or #PF.  #UD requires a zero error code and address.  #GP accepts an error
> +code verbatim and requires a zero address.  #PF also accepts the error code
> +verbatim and uses ``address`` as CR2.  Userspace may dirty synchronized REGS
> +when requesting an exception, e.g. to preserve partial progress from a
> +high-bandwidth backdoor transfer.  KVM applies the synchronized registers
> +before queuing the exception. 

Does all that work as expected under FRED?

I've added something slightly similar for Hyper-V hcalls in 
https://lore.kernel.org/all/20261111205836.4186584-3-dwmw2@xxxxxxxxxxxxx/

I only know of a need to inject #UD, so it was a simple flag — but I'm
wondering if we should strive for some kind of consistency in the
userspace API?

And I wonder if the cleaner answer in both cases is just to give
userspace a way to cancel the pending hypercall completion and use
KVM_SET_VCPU_EVENTS instead of piling all this stuff into the hcall
structs? It could even just be a KVM_VCPUEVENT_ flag to make it cancel
the hypercall completion?

Attachment: smime.p7s
Description: S/MIME cryptographic signature