[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180104231221.GA13348@redhat.com>
Date: Fri, 5 Jan 2018 00:12:21 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
Dave Hansen <dave.hansen@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Arjan Van De Ven <arjan.van.de.ven@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts
On Thu, Jan 04, 2018 at 11:33:21PM +0100, Peter Zijlstra wrote:
> So not only did we add a CR3 write, we're now adding an MSR write to the
> entry/exit paths. Please tell me that these are 'fast' MSRs? Given
> people are already reporting stupid numbers with just the existing
> PTI/CR3, what kind of pain are we going to get from adding this?
On SkyLake it costs roughly the same as cr3 write with bit 63 set, but
SkyLake then runs faster with IBRS enabled too. On earlier CPUs
enabling IBRS slows down CPU quite a bit, so the primary concern is
for older CPUs and the MSR write is the last worry there.
ibrs 2 will set IBRS all the time (only guest mode will alter it and
it'll always be restored to IBRS set during vmexit) so there will be
no cost on kernel enter/exit (also no cost in vmenter vmexit if guest
leaves it always set). Future silicon will like to run in ibrs 2 mode
always, but current one runs faster at ibrs 1 despite the MSR write
for most workloads (kernel builds etc..).
Thanks,
Andrea
Powered by blists - more mailing lists