On Wed, Jul 08, 2026, Venkatesh Srinivas wrote: > On Mon, Jul 6, 2026 at 6:34 PM Jim Mattson <[email protected]> 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. > > Would not passing through this feature when erratum 1096 is present > simplify this?
I don't think so? I'd be fine with KVM propagating the erratum to the guest, i.e. not trying to fixup the decode-assist information if hardware failed to provide it. Jim mentioned the erratum because the only way for the erratum to exist is if hardware re-reads memory after the initial fetch, and so exactly how and when hardware/KVM reads the bytes is a micro-architectural detail. I.e. the mere existence of the erratum simplifies KVM's implementation, because we don't have to strictly read and propagate the entire 15 bytes from KVM's equilavent of the fetch phase.
