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

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 06, 2026, Jim Mattson wrote:
> On Mon, Jul 6, 2026 at 8:25 PM Jim Mattson <jmattson@google.com> wrote:
> >
> > On Mon, Jul 6, 2026 at 8:21 PM Sean Christopherson <seanjc@google.com> 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@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.
> 
> What about the case of a userspace-injected #PF while running L2, when
> L1 intercepts #PF?

That can/will be handled by the fallback logic of reading the code stream on-demand?