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


Reply via email to