On Tue, Jul 7, 2026 at 5:53 PM Tina Zhang <[email protected]> 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. > > The practical issue that triggered this is Hyper-V as L1 in Hyper-V > appears to require DecodeAssists before enabling nested SVM for L2, so > the visible benefit is enabling that nested virtualization > configuration. Without exposing DecodeAssists to L1 Hyper-V, the nested > svm cases like this (L0 KVM + L1 Hyper-V + L2 KVM) would be broken, > because the Hyper-V doesn't think the platform have the nested > virtualization capability, although the hardware supports it.
Interesting, that's basically running QEMU in WSL, right? Probably worth including the motivation going forward. > > I agree that fully virtualizing DecodeAssists is not straightforward, > and the complexity needs to be justified. My intent is to keep the > implementation biased toward propagating already-available decode state: > hardware VMCB02 bytes for hardware exits, emulator-provided bytes for > synthesized exits when available, and only using an on-demand fetch as a > fallback where no decoded state is available. > > Thanks, > Tina >
