Re: [PATCH v9 12/22] KVM: VMX: Virtualize FRED event_data

[Xin Li]

> On Jan 29, 2026, at 9:21 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> 
>> Just to confirm, you are referring to requeueing an original event
>> via vmx_complete_interrupts(), right?
>> 
>> Regardless of whether FRED or IDT is in use, the event payload is delivered
>> into the appropriate guest state and then invalidated in
>> kvm_deliver_exception_payload():
>> 
>>       1) CR2 for #PF
>> 
>>       2) DR6 for #DB
>> 
>>       3) guest_fpu.xfd_err for #NM (in handle_nm_fault_irqoff())
>> 
>> We should be able to recover the FRED event data from there.
>> 
>> Alternatively, we could drop the original event and allow the hardware to
>> regenerate it upon resuming the guest.  However, this breaks #DB delivery,
>> as debug exceptions sometimes are triggered post-instruction.
>> 
>> 
>> Sean, does it make sense to recover the FRED event data from guest CPU state?
> 
> I think some bits in DR6 are "sticky", and so unless the guest has explicitly cleared DR6 the event data isn't necessarily derivable from DR6. However, the FRED event data for #DB is directly based on the data already reported by VTx (for exactly the same reason – knowing what the *currently taken* trap represents.)

Yeah, it's important to keep in mind that DR6 bits are 'sticky'.

Regarding vmx_complete_interrupts(), when a VM migration occurs immediately
following a VM exit with a valid original event saved in the VMCS, we can
safely assume the guest DR6 state remains consistent with the original event
data because there is no chance for guest OS to modify DR6.