linux-kernel - Re: [PATCH v5 1/1] x86: kvm: svm: set up ERAPS support for guests

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: <aKX1VZ90_wBxMI7l@google.com>
Date: Wed, 20 Aug 2025 09:18:29 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Amit Shah <amit@...nel.org>
Cc: Tom Lendacky <thomas.lendacky@....com>, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org, x86@...nel.org, linux-doc@...r.kernel.org, bp@...en8.de, 
	tglx@...utronix.de, peterz@...radead.org, jpoimboe@...nel.org, 
	pawan.kumar.gupta@...ux.intel.com, corbet@....net, mingo@...hat.com, 
	dave.hansen@...ux.intel.com, hpa@...or.com, pbonzini@...hat.com, 
	daniel.sneddon@...ux.intel.com, kai.huang@...el.com, sandipan.das@....com, 
	boris.ostrovsky@...cle.com, Babu.Moger@....com, david.kaplan@....com, 
	dwmw@...zon.co.uk, andrew.cooper3@...rix.com, amit.shah@....com
Subject: Re: [PATCH v5 1/1] x86: kvm: svm: set up ERAPS support for guests

On Wed, May 28, 2025, Amit Shah wrote:
> On Mon, 2025-05-19 at 16:22 -0500, Tom Lendacky wrote:
> > > +static inline void vmcb_set_flush_guest_rap(struct vmcb *vmcb)
> > > +{
> > > +	vmcb->control.erap_ctl |= ERAP_CONTROL_FLUSH_RAP;
> > > +}
> > > +
> > > +static inline void vmcb_clr_flush_guest_rap(struct vmcb *vmcb)
> > > +{
> > > +	vmcb->control.erap_ctl &= ~ERAP_CONTROL_FLUSH_RAP;
> > > +}
> > > +
> > > +static inline void vmcb_enable_extended_rap(struct vmcb *vmcb)
> > 
> > s/extended/larger/ to match the bit name ?
> 
> I also prefer it with the "larger" name, but that is a confusing bit
> name -- so after the last round of review, I renamed the accessor
> functions to be "better", while leaving the bit defines match what the
> CPU has.
> 
> I don't mind switching this back - anyone else have any other opinions?

They both suck equally?  :-)

My dislike of "larger" is that it's a relative and intermediate term.  What is
the "smaller" size?  Is there an "even larger" or "largest size"?

"extended" doesn't help in any way, because that simply "solves" the problem of
size ambiguity by saying absolutely nothing about the size.

I also dislike "allow", because in virtualization context, "allow" usually refers
to what the _guest_ can do, but in this case "allow" refers to what the CPU can
do.

If we want to diverge from the APM, my vote would be for something like

  ERAP_CONTROL_FULL_SIZE_RAP