On Mon, Jun 29, 2026 at 5:56 AM Tina Zhang <[email protected]> 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.
