On 7/7/2026 9:32 AM, Jim Mattson wrote:
On Mon, Jul 6, 2026 at 5:02 PM Tina Zhang <[email protected]> wrote:
I will take another look for the next version and try to handle the
remaining pieces properly, while also making sure we don't expose stale
or incorrectly synthesized decode-assist state for emulated exits.
Naples erratum 1096 seems to imply that the instruction bytes stored
in the VMCB are not necessarily the same instruction bytes that were
fetched and decoded to lead to the #PF/#NPF. Hence, in the case of
emulation, it might be sufficient to read the instruction bytes quite
late in nested_svm_vmexit(). That would certainly simplify the
plumbing.
Thanks for the suggestion, and for pointing me at Naples erratum 1096.
I wasn't aware of that erratum.
My understanding is that late fetching/decoding from guest RIP is not
strictly equivalent to preserving the exact bytes observed by the
original decoder, as the code bytes or translations could theoretically
change in between. But the suggested workaround for erratum 1096 also
tells the hypervisor to decode the instruction at the instruction
pointer when GuestInstrBytes cannot be used, so it seems that this is an
acceptable model/fallback.
For KVM-synthesized/emulated #PF/#NPF nested VM-Exits there is no fresh
hardware GuestInstrBytes state to propagate to VMCB12. So I agree that
it should be simpler to avoid plumbing instruction bytes from the
emulator, and instead fetch the bytes late when constructing the nested
VM-Exit for L1.
I'll try this direction first.
Thanks,
Tina