Re: [PATCH 0/2] KVM: nSVM: Expose DecodeAssists to L1

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 07, 2026, Tina Zhang wrote:
> 
> 
> On 7/7/2026 9:32 AM, Jim Mattson wrote:
> > On Mon, Jul 6, 2026 at 5:02 PM Tina Zhang <zhang_wei@open-hieco.net> wrote:
> > 
> > > I will take another look for the next version and try to handle the
> > > remaining pieces properly, while also making sure we don't expose stale
> > > or incorrectly synthesized decode-assist state for emulated exits.
> > 
> > Naples erratum 1096 seems to imply that the instruction bytes stored
> > in the VMCB are not necessarily the same instruction bytes that were
> > fetched and decoded to lead to the #PF/#NPF. Hence, in the case of
> > emulation, it might be sufficient to read the instruction bytes quite
> > late in nested_svm_vmexit(). That would certainly simplify the
> > plumbing.

The plumbing doesn't seem all that complex though.

> Thanks for the suggestion, and for pointing me at Naples erratum 1096. I
> wasn't aware of that erratum.
> 
> My understanding is that late fetching/decoding from guest RIP is not
> strictly equivalent to preserving the exact bytes observed by the original
> decoder, as the code bytes or translations could theoretically change in
> between. But the suggested workaround for erratum 1096 also tells the
> hypervisor to decode the instruction at the instruction pointer when
> GuestInstrBytes cannot be used, so it seems that this is an acceptable
> model/fallback.
> 
> For KVM-synthesized/emulated #PF/#NPF nested VM-Exits there is no fresh
> hardware GuestInstrBytes state to propagate to VMCB12. So I agree that it
> should be simpler to avoid plumbing instruction bytes from the emulator, and
> instead fetch the bytes late when constructing the nested VM-Exit for L1.
> 
> I'll try this direction first.

I'd rather not, at least not as the primary way.  It's going to raise a different
set of issues, e.g. how to behave if reading guest memory fails.  That's probably
unavoidable, e.g. if reading the INVPCID descriptor fails, then KVM doesn't even
have a pre-decoded instruction to work with, but it should ideally be a last
resort.

E.g. where the NULL case triggers an on-demand read of guest memory.

diff --git arch/x86/kvm/svm/nested.c arch/x86/kvm/svm/nested.c
index ba985a02208a..812af3a8d8b9 100644
--- arch/x86/kvm/svm/nested.c
+++ arch/x86/kvm/svm/nested.c
@@ -42,6 +42,7 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu *vcpu,
        struct vcpu_svm *svm = to_svm(vcpu);
        struct vmcb *vmcb = svm->vmcb;
        u64 fault_stage;
+       u8 *insn_bytes;
 
        /*
         * For hardware NPF exits, the GUEST_FAULT_STAGE bits are only
@@ -68,7 +69,14 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu *vcpu,
                                    (fault->error_code & ~PFERR_GUEST_FAULT_STAGE_MASK);
        vmcb->control.exit_info_2 = fault->address;
 
-       nested_svm_vmexit(svm);
+       if (from_hardware)
+               insn_bytes = svm->nested.vmcb02.ptr->control.insn_bytes;
+       else if (vcpu->arch.emulate_ctxt->eip == kvm_rip_read(vcpu))
+               insn_bytes = vcpu->arch.emulate_ctxt->fetch.data
+       else
+               insn_bytes = NULL;
+
+       nested_svm_vmexit(svm, insn_bytes);
 }
 
 static u64 nested_svm_get_tdp_pdptr(struct kvm_vcpu *vcpu, int index)