On Mon, Jul 6, 2026 at 8:21 PM Sean Christopherson <[email protected]> wrote: > > On Tue, Jul 07, 2026, Tina Zhang wrote: > > > > > > 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. > > The plumbing doesn't seem all that complex though. > > > 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. > > I'd rather not, at least not as the primary way. It's going to raise a > different > set of issues, e.g. how to behave if reading guest memory fails. That's > probably > unavoidable, e.g. if reading the INVPCID descriptor fails, then KVM doesn't > even > have a pre-decoded instruction to work with, but it should ideally be a last > resort. > > E.g. where the NULL case triggers an on-demand read of guest memory. > > diff --git arch/x86/kvm/svm/nested.c arch/x86/kvm/svm/nested.c > index ba985a02208a..812af3a8d8b9 100644 > --- arch/x86/kvm/svm/nested.c > +++ arch/x86/kvm/svm/nested.c > @@ -42,6 +42,7 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu > *vcpu, > struct vcpu_svm *svm = to_svm(vcpu); > struct vmcb *vmcb = svm->vmcb; > u64 fault_stage; > + u8 *insn_bytes; > > /* > * For hardware NPF exits, the GUEST_FAULT_STAGE bits are only > @@ -68,7 +69,14 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu > *vcpu, > (fault->error_code & > ~PFERR_GUEST_FAULT_STAGE_MASK); > vmcb->control.exit_info_2 = fault->address; > > - nested_svm_vmexit(svm); > + if (from_hardware) > + insn_bytes = svm->nested.vmcb02.ptr->control.insn_bytes; > + else if (vcpu->arch.emulate_ctxt->eip == kvm_rip_read(vcpu)) > + insn_bytes = vcpu->arch.emulate_ctxt->fetch.data
Won't this be shy of the architected 15 bytes if RIP is within 15 bytes of a page crossing and the instruction ends before the page crossing? > + else > + insn_bytes = NULL; > + > + nested_svm_vmexit(svm, insn_bytes); > } > > static u64 nested_svm_get_tdp_pdptr(struct kvm_vcpu *vcpu, int index)
