[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1518509560.12890.29.camel@infradead.org>
Date: Tue, 13 Feb 2018 08:12:40 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: tglx@...utronix.de, x86@...nel.org, kvm@...r.kernel.org,
torvalds@...ux-foundation.org, pbonzini@...hat.com,
linux-kernel@...r.kernel.org, arjan.van.de.ven@...el.com,
dave.hansen@...el.com
Subject: Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future
CPUs
On Tue, 2018-02-13 at 08:47 +0100, Ingo Molnar wrote:
> * David Woodhouse <dwmw@...zon.co.uk> wrote:
>
> >
> > +extern enum spectre_v2_mitigation spectre_v2_enabled;
>
> This needs to be exported if the KVM module wants to use it.
>
> >
> > +static inline bool spectre_v2_ibrs_all(void)
> > +{
> > + return spectre_v2_enabled == SPECTRE_V2_IBRS_ALL;
> > +}
> >
> > + if (vmx->spec_ctrl && !spectre_v2_ibrs_all())
> >
> > + if (!spectre_v2_ibrs_all) {
>
> erm, that's a function, not a flag ...
0-day pointed out the latter, which is already fixed in the git tree
ready for the next resend. Not the former though.
I can export it. It does make me ponder for a second whether I should
have gone with my first instinct just to make it another cpufeature
flag like the others. But no, the excuse for doing that for the others
was that it *needs* to be one for using alternatives. And this flag
*isn't* used for alternatives, so it seems a little (more) wrong.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists