On Tue, Jul 7, 2026 at 8:37 AM Sean Christopherson <[email protected]> wrote: > > On Tue, Jul 07, 2026, Jim Mattson wrote: > > On Tue, Jul 7, 2026 at 7:41 AM Sean Christopherson <[email protected]> > > wrote: > > > > > > insn = ctxt->fetch.data; > > > if (ctxt->eip == kvm_rip_read(vcpu)) > > > insn_len = ctxt->fetch.end - ctxt->fetch.ptr; > > > > > > for (len = X86_MAX_INSTRUCTION_LENGTH - insn_len; len >= 0; > > > len--) { > > > if (!kvm_fetch_guest_virt(vcpu, kvm_rip_read(vcpu) + > > > insn_len, > > > &insn[insn_len], len, NULL)) > > > break; > > > } > > > > This split doesn't bother you? > > What split? Do you mean reading some bytes from the emulator, and some at the > time of #VMEXIT? If so: no. IMO, the most important thing in practice is to > capture the actual bytes used to decode the instruction that led to the #NPF.
Yes, that was the split I was referring to. > Exactly how and when the "CPU" reads the bytes is a micro-architectural > detail, > so I don't have any qualms from an architectural-correctness perspective. When I requested this feature, I think I made it clear that I wanted the actual instruction bytes used to decode the instruction, rather than bytes asynchronously fetched through the data path. It wasn't until I encountered the Naples erratum that I realized AMD hadn't implemented the feature as requested. Since there is no guarantee that the instruction bytes are actually relevant, I concede that 'exactly how and when the "CPU" reads the bytes is a micro-architectural detail.'
