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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aFl1PcnVuYuELvRQ@google.com>
Date: Mon, 23 Jun 2025 08:39:41 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Sohil Mehta <sohil.mehta@...el.com>, Xin Li <xin@...or.com>, x86@...nel.org, 
	linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Peter Zijlstra <peterz@...radead.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	Tony Luck <tony.luck@...el.com>, Zhang Rui <rui.zhang@...el.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Andrew Cooper <andrew.cooper3@...rix.com>, 
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Jacob Pan <jacob.pan@...ux.microsoft.com>, 
	Andi Kleen <ak@...ux.intel.com>, Kai Huang <kai.huang@...el.com>, 
	Sandipan Das <sandipan.das@....com>, linux-perf-users@...r.kernel.org, 
	linux-edac@...r.kernel.org, kvm@...r.kernel.org, linux-pm@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v7 02/10] x86/fred: Pass event data to the NMI entry point
 from KVM

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