Re: [PATCH v4 4/9] KVM: nSVM: Propagate hardware DecodeAssist bytes to VMCB12

On Fri, Aug 21, 2026 at 12:47 AM Tina Zhang <[email protected]> wrote:
>
> Hi Sean and Jim,
>
> Before posting v5, I'd like to get your opinion on how to track the
> instruction-byte source for a delayed nested #PF VM-Exit.
>
> A hardware #PF may first be handled by KVM and then queued for
> reflection to L1.  When constructing the nested VM-Exit later, nSVM
> needs to know whether the queued #PF still corresponds to the
> DecodeAssist bytes in VMCB02.  Similarly, an emulator-originated #PF
> needs to retain that provenance so that KVM uses the emulator fetch
> cache only for the exception that actually came from that emulator context.
>
> Keeping this information as independent state in svm_nested_state is
> fragile.  For example, userspace may clear or replace the pending
> exception, leaving the SVM state associated with an event that no longer
> exists.  In v5, I am therefore associating the provenance with the
> queued exception itself.  Userspace-restored exceptions have neither
> hardware nor emulator provenance and use the on-demand fetch fallback.
>
> The part I am unsure about is how this should be represented.  The
> minimal implementation adds:
>
>            bool has_emulator_context;
>            bool has_hardware_pf_state;
>
> to struct kvm_queued_exception.  However, these fields are meaningful
> only for vcpu->arch.exception_vmexit, while the same structure is also
> used for the normal vcpu->arch.exception queue.
>
> An alternative would be to introduce a wrapper, for example:
>
>            struct kvm_exception_vmexit {
>                    struct kvm_queued_exception exception;
>                    bool has_emulator_context;
>                    bool has_hardware_pf_state;
>            };
>
> This keeps the VM-Exit provenance out of the normal exception structure,
> but requires mechanical change to the generic x86 and VMX references to
> exception_vmexit.
>
> Do you have a preference between these approaches, or is there another
> way you would recommend representing this state?

Honestly, I would not even try to optimize #PF VM-exits. KVM only
intercepts #PF when TDP is disabled. Since SVM-capable CPUs have
always supported TDP, that's a bizarre configuration. I suspect it's
equally bizarre for any other L1 hypervisor.

Can we just read the instruction bytes (using our slow fallback) when
we synthesize a #PF VM-exit from L2 to L1?