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

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 08, 2026, Venkatesh Srinivas wrote:
> On Mon, Jul 6, 2026 at 6:34 PM Jim Mattson <jmattson@google.com> 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.
> 
> Would not passing through this feature when erratum 1096 is present
> simplify this?

I don't think so?  I'd be fine with KVM propagating the erratum to the guest,
i.e. not trying to fixup the decode-assist information if hardware failed to
provide it.

Jim mentioned the erratum because the only way for the erratum to exist is if
hardware re-reads memory after the initial fetch, and so exactly how and when
hardware/KVM reads the bytes is a micro-architectural detail.  I.e. the mere
existence of the erratum simplifies KVM's implementation, because we don't have
to strictly read and propagate the entire 15 bytes from KVM's equilavent of the
fetch phase.