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.
