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

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 08, 2026, Tina Zhang wrote:
> On 7/8/2026 6:34 AM, Yosry Ahmed wrote:
> > On Mon, Jun 29, 2026 at 08:52:03PM +0800, Tina Zhang wrote:
> > > The SVM DecodeAssists feature is reported in CPUID
> > > Fn8000_000A_EDX[7].  When available, hardware provides the length and bytes
> > > of the intercepted instruction in the VMCB, allowing a hypervisor to consume
> > > the decode information directly instead of re-decoding the instruction in
> > > software on relevant VM-Exit paths.
> > > 
> > > KVM currently does not expose DecodeAssists to nested SVM guests, even when
> > > the host supports it, and does not propagate the hardware-provided
> > > instruction length and bytes from VMCB02 to VMCB12 on nested VM-Exit.  This
> > > leaves L1 with an incomplete virtual SVM CPUID model and prevents L1 from
> > > using the same hardware-assisted decode information that KVM receives for
> > > L2 exits.
> > > 
> > > The missing virtualization was observed in practice with Hyper-V as L1,
> > > where the absence of DecodeAssists prevented nested SVM from being made
> > > available to L2 guests.  The fix is not Hyper-V specific.  Complete nested
> > > SVM virtualization of DecodeAssists by advertising the feature to L1 when
> > > supported by hardware, and by copying the decode-assist fields into VMCB12
> > > on nested VM-Exit.
> > > 
> > > Add a selftest that triggers a nested page fault from L2 and verifies that
> > > L1 sees a non-zero instruction length and instruction bytes matching the
> > > faulting instruction.
> > 
> > Taking a large step back from all the discussions in the other replies:
> > Is there a measurable performance improvement? Not trying to say we
> > shouldn't do this, but we should at least see what we're trading this
> > complexity for, it's obviously not straigtforward to fully virtualize
> > decode assists.
> 
> I don't have a meaningful performance number yet. My current understanding
> is that the main value of the series is more about architectural
> completeness and enabling the Hyper-V L1 use case than about a direct
> performance win.

Yeah, and I wouldn't be at all surprised if VMware follows suit in the future.
E.g. see commit 176bfc5b17fe ("KVM: nSVM: Advertise support for flush-by-ASID").