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

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 07, 2026, Jim Mattson wrote:
> On Tue, Jul 7, 2026 at 8:37 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Tue, Jul 07, 2026, Jim Mattson wrote:
> > > On Tue, Jul 7, 2026 at 7:41 AM Sean Christopherson <seanjc@google.com> wrote:
> > > >
> > > >         insn = ctxt->fetch.data;
> > > >         if (ctxt->eip == kvm_rip_read(vcpu))
> > > >                 insn_len = ctxt->fetch.end - ctxt->fetch.ptr;
> > > >
> > > >         for (len = X86_MAX_INSTRUCTION_LENGTH - insn_len; len >= 0; len--) {
> > > >                 if (!kvm_fetch_guest_virt(vcpu, kvm_rip_read(vcpu) + insn_len,
> > > >                                           &insn[insn_len], len, NULL))
> > > >                         break;
> > > >         }
> > >
> > > This split doesn't bother you?
> >
> > What split?  Do you mean reading some bytes from the emulator, and some at the
> > time of #VMEXIT?  If so: no.  IMO, the most important thing in practice is to
> > capture the actual bytes used to decode the instruction that led to the #NPF.
> 
> Yes, that was the split I was referring to.
> 
> > Exactly how and when the "CPU" reads the bytes is a micro-architectural detail,
> > so I don't have any qualms from an architectural-correctness perspective.
> 
> When I requested this feature, I think I made it clear that I wanted
> the actual instruction bytes used to decode the instruction, rather
> than bytes asynchronously fetched through the data path.

FWIW, what I'm suggesting gets us as close to that ideal as is possible, I think.
If KVM emulates an instruction in response to an #PF or #NPF exit, then the
emulator will use the information from the VMCB, and so the above code will also
use the code stream that hardware provided.  If hardware provided fewer than
15 bytes for whatever, KVM will try to fill in the gaps, but KVM can't possibly
have decoded those bytes, so there's disconnect between what was emulated versus
what was read later on.

If KVM emulates without information from the VMCB, then the emulator's code fetch
is the "source of truth", and everything else in the above again holds true.

> It wasn't until I encountered the Naples erratum that I realized AMD hadn't
> implemented the feature as requested.

Yeah.  I've poked AMD folks about this once or twice, the answer is (amusingly)
that plumbing the bytes from fetch+decode all the way to the #VMEXIT is painful,
and so hardware just reads memory at the time of #VMEXIT.

> Since there is no guarantee that the instruction bytes are actually
> relevant, I concede that 'exactly how and when the "CPU" reads the
> bytes is a micro-architectural detail.'

KVM's emulator would actually be doing better than hardware, because at least KVM
wouldn't report different bytes than what it emulated :-)