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.
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
