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

[Zack Rusin]

On Thu, Nov 12, 2026 at 3:25 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> 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?

Sure, I'll add some reserved space and require it to be zero on completion.

>
> > +                                     } 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 can't say for sure because I haven't looked at or tried the proposed
KVM FRED support series yet. The completion doesn't build any delivery
state itself, it uses kvm_queue_exception{,_e}() and
kvm_inject_page_fault() with the #PF address as the exception payload,
so it depends on FRED support turning that payload into the event
data, as for KVM's own #PF injections (i.e. if the proposed kvm fred
support is complete I'd expect it to work, but that's just a guess :)
).

> 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?

I agree that this would be cleaner, and if KVM grows such a flag,
VMware userspace could use it too.  But it's new API in
KVM_SET_VCPU_EVENTS, and we'd need to agree which completions it may
cancel: simply clearing the callback leaves pending I/O state behind
for PIO and MMIO, and KVM_EXIT_HYPERCALL also covers TDX completions
with different semantics.  So I'd rather not make this series depend
on it because it significantly increases its scope.

z

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature