[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03ee75fb-8903-948e-66c6-0c1dc54d8cff@linux.intel.com>
Date: Thu, 4 Jan 2018 12:26:43 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dave Hansen <dave.hansen@...el.com>,
Andrea Arcangeli <aarcange@...hat.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 01/04/2018 12:00 PM, Greg KH wrote:
> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>>
>> That is a minor inefficiency only, but we can eliminate it by saving
>> the MSR when entering the NMI in save_paranoid and restoring it when
>> exiting the NMI.
>
> Any hints as to what exactly "minor" means in cycles here? :)
>
The current implementation does not have this inefficiency. The
comment is to explain why we need to save the IBRS state in save_paranoid.
The issue is if we don't save the IBRS state for NMI,
For nested interrupts, it is hard to
figure out when we are returning from NMI, whether we are
returning to user space or kernel space. And if we do the safe
thing by leaving IBRS on, there is a possibility that we may
return to user space with IBRS enabled, which will affect performance.
The possibility of hitting this is minor, but still we want
to eliminate it.
Thanks.
Tim
Powered by blists - more mailing lists