On June 23, 2025 8:39:41 AM PDT, Sean Christopherson <sea...@google.com> wrote: >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.)
I agree, let's stick to that for now, since this is a kernel internal interface and nothing consumes it. After all, it will save a handful of cycles. I will still check into the "pinky swear", though.
