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
+ else
+ insn_bytes = NULL;
+
+ nested_svm_vmexit(svm, insn_bytes);
}
static u64 nested_svm_get_tdp_pdptr(struct kvm_vcpu *vcpu, int index)
