if (kvm_is_fred_enabled(vcpu)) {u64 event_data = 0;if (is_debug(intr_info))/** Compared to DR6, FRED #DB event data saved on* the stack frame have bits 4 ~ 11 and 16 ~ 31* inverted, i.e.,* fred_db_event_data = dr6 ^ 0xFFFF0FF0UL*/event_data = vcpu->arch.dr6 ^ DR6_RESERVED;else if (is_page_fault(intr_info))event_data = vcpu->arch.cr2;else if (is_nm_fault(intr_info))event_data =- to_vmx(vcpu)->fred_xfd_event_data;
IMO, deriving an event_data from CR2/DR6 is a little short-sighted because the event_data and CR2/DR6 __can__ be different, e.g., L1 VMM __can__ set CR2 to A and event_data field to B (!=A) when injecting #PF.
VMM should guarantee a FRED guest _sees_ consistent values in CR6/DR6 and event data. If not it's just a VMM bug that we need to fix.
And this approach cannot be extended to handle a (future) exception whose event_data isn't tied to a dedicated register like CR2/DR6.
See below.
Adding a new field fred_xfd_event_data in struct vcpu has problems too: fred_xfd_event_data gets lost during migration;
I'm not bothered, because this is not hard to fix, right?
strickly speaking, event_data is tied to an exception rather than a CPU. e.g., the CPU may detect a nested exception when delivering one and both have their own event_data.
No, don't get me wrong. An event data has to be _regenerated_ after a nested exception is handled and the original instruction flow is restarted. sometimes the original event could be gone.
We don't say an event data is tied to an exception or a CPU, which is just confusing, or misleading.
I think we can make event_data a property of exceptions. i.e., add a payload2 to struct kvm_queued_exception. and add new APIs to kvm_queue_exception* family to accept a payload2 and in VMX code, just program payload2 to the VMCS event_data field if FRED is enabled. KVM ABI should be extended as well to pass payload2 to userspace like how the payload is handled in kvm_vcpu_ioctl_x86_get/put_vcpu_events.
Yes, it's very likely that we will need to add a payload2 in future, but NOT now. 2 reasons:
1) The first-generation FRED is designed to NOT go too far from what IDT can do. And FRED event data is conceptually an alias of CR2/DR6 in the latest FRED spec (not considering xfd event data for now). And the existing payload is a nice match for now;
2) FRED is an extendable CPU architecture, which allows the structure of event data to become way bigger and complicated. Let's not assume anything and add a payload2 too early.