On Fri, Jun 20, 2025, H. Peter Anvin wrote: > On 2025-06-20 16:18, Sean Christopherson wrote: > > > > > > So I was thinking about this, and wonder: how expensive is it to get the > > > event data exit information out of VMX? If it is not very expensive, it > > > would arguably be a good thing to future-proof by fetching that > > > information, > > > even if it is currently always zero. > > > > It's trivially easy to do in KVM, and the cost of the VMREAD should be less > > than > > 20 cycles. So quite cheap in the grand scheme. If VMREAD is more costly > > than > > that, then we have bigger problems :-) > > > > LOL. Since it is up to you, Paulo, etc. to decide how to do the tradeoffs > formaintainability, debuggability and performance in KVM I am guessing this > is a vote in favor? (You can always take it out if it is a performance > problem, until such time that the kernel itself starts consuming this > information for reasons currently unknown.)
Unless you can pinky swear that vmcs.EXIT_QUALIFICATION will provide event data for IRQ exits, then I'd prefer to pass '0' unconditionally. '0' will always be safe, if potentially suboptimal. But passing what could in theory be something other than FRED-formatted event data could lead to buggy behavior. Per the FRED spec, Revision 7.0, exit-qualification doesn't hold event data for IRQ exits. For some events for which event data is defined (see Section 5.2.1), the event data is saved in the exit-qualification field. (This is done for #DB, #PF, and NMI.)
