[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBBA4A2.2070501@redhat.com>
Date: Tue, 22 May 2012 17:37:22 +0300
From: Avi Kivity <avi@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: linux-kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Paul Turner <pjt@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: NMI vs #PF clash
On 05/22/2012 05:27 PM, Steven Rostedt wrote:
> On Tue, 2012-05-22 at 17:20 +0300, Avi Kivity wrote:
>> On 05/22/2012 05:09 PM, Steven Rostedt wrote:
>> >> >
>> >> > Or we could just have the NMI always restore the cr2 register.
>> >>
>> >> IMO that's best.
>> >
>> > OK, I can whip up a patch, but I wont push that in till 3.6.
>> >
>>
>> Thanks. Something I've noticed is that writing cr2 is slow, so you may
>> want to write it only if it has changed (which should be very rare).
>>
>
> Is reading it fast? Then we could do a two reads and only write when
> needed.
The upside is 70 cycles on one machine, see d3edefc0035669.
>
> Something like this pseudo assembly
>
> mov cr2, rax
> push rax
>
> call do_nmi
>
> pop rax
> mov cr2, rbx
> cmp rax, rbx
> be skip
> mov rax, cr2
> skip:
>
Yes, provided no exceptions can happen at those points.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists