On Tue, Jul 07, 2026, Jim Mattson wrote: > 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.
FWIW, what I'm suggesting gets us as close to that ideal as is possible, I think. If KVM emulates an instruction in response to an #PF or #NPF exit, then the emulator will use the information from the VMCB, and so the above code will also use the code stream that hardware provided. If hardware provided fewer than 15 bytes for whatever, KVM will try to fill in the gaps, but KVM can't possibly have decoded those bytes, so there's disconnect between what was emulated versus what was read later on. If KVM emulates without information from the VMCB, then the emulator's code fetch is the "source of truth", and everything else in the above again holds true. > It wasn't until I encountered the Naples erratum that I realized AMD hadn't > implemented the feature as requested. Yeah. I've poked AMD folks about this once or twice, the answer is (amusingly) that plumbing the bytes from fetch+decode all the way to the #VMEXIT is painful, and so hardware just reads memory at the time of #VMEXIT. > 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.' KVM's emulator would actually be doing better than hardware, because at least KVM wouldn't report different bytes than what it emulated :-)
