[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1519125725.7876.117.camel@infradead.org>
Date: Tue, 20 Feb 2018 11:22:05 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: karahmed@...zon.de, x86@...nel.org, kvm@...r.kernel.org,
torvalds@...ux-foundation.org, pbonzini@...hat.com,
linux-kernel@...r.kernel.org, bp@...en8.de, peterz@...radead.org,
jmattson@...gle.com, rkrcmar@...hat.com,
arjan.van.de.ven@...el.com, dave.hansen@...el.com, mingo@...nel.org
Subject: Re: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on
future CPUs
On Tue, 2018-02-20 at 11:42 +0100, Thomas Gleixner wrote:
>
> > > However, Paolo is very insistent that taking the trap every time is
> > > actually a lot *slower* than really frobbing IBRS on certain
> > > microarchitectures, so my hand-waving "pfft, what did they expect?" is
> > > not acceptable.
> > >
> > > Which I think puts us back to the "throwing the toys out of the pram"
>
> There are no more toys in the pram. I threw them all out weeks ago ...
One option is to take the patch as-is¹ with the trap on every access.
As soon as Intel define that 'IBRS_ALL_AND_THE_BIT_IS_A_NOOP' bit in
MSR_IA32_ARCH_CAPABILITIES, *then* we can expose it to guests directly
again just as we do at the moment.
That way, the slowdown that Paolo is concerned about is limited to a
small set of current CPUs on which we're mostly unlikely to care too
much about KVM anyway.
¹ as-is, except I really will go and turn the IA32_ARCH_CAPABILITIES
bits into scattered cpufeatures before I repost it.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)
Powered by blists - more mailing lists