Re: [PATCH 1/2] KVM: nSVM: Virtualize DecodeAssists for nested guests

[Jim Mattson]

On Mon, Jun 29, 2026 at 5:56 AM Tina Zhang <zhang_wei@xxxxxxxxxxxxxx> wrote:
>
> Hardware records DecodeAssist information, i.e. the instruction length and
> bytes, in the VMCB for exits such as #NPF.  KVM does not currently expose
> that information when an L2 exit is reflected to L1, so a nested hypervisor
> cannot consume the hardware-provided decode state and may need to fetch and
> decode the L2 instruction itself.
>
> Advertise DecodeAssists to L1 when the host supports it, and copy
> insn_len/insn_bytes from VMCB02 to VMCB12 for nested VM-Exits that
> reflect a real hardware exit.  Gate the copy on L1's guest CPUID so the
> advertised feature and the propagated state stay in sync.
>
> Report decode information only for exits that actually have fresh hardware
> state.  KVM synthesizes several nested VM-Exits, e.g. VMRUN failures,
> synthetic #NPF exits, reflected exceptions, and interrupt/NMI windows, that
> do not carry VMCB02 DecodeAssist output.  Track only the verbatim VMCB02
> reflection path with nested.decode_assists_valid, clear VMCB02's decode
> fields before VMRUN, and clear VMCB12's fields for ineligible exits.  Use
> insn_len == 0 to tell L1 that no decode information is available, and avoid
> exposing stale bytes from a previous L2 exit.

You can't just set instr_len to 0 on a whim. Per the APM, "The default
number of bytes is always 15. Fewer bytes are returned only if a fault
occurs while fetching." Every #PF and #NPF VM-exit to L1 *must*
provide this information, even in cases where you can't simply copy
the information from VMCB02.