Re: [PATCH v7 02/10] x86/fred: Pass event data to the NMI entry point from KVM

[Sean Christopherson <seanjc@google.com>]

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.)