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

[Jim Mattson]

On Mon, Jul 6, 2026 at 8:21 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxx> 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

Won't this be shy of the architected 15 bytes if RIP is within 15
bytes of a page crossing and the instruction ends before the page
crossing?

> +       else
> +               insn_bytes = NULL;
> +
> +       nested_svm_vmexit(svm, insn_bytes);
>  }
>
>  static u64 nested_svm_get_tdp_pdptr(struct kvm_vcpu *vcpu, int index)