[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337698229.13348.46.camel@gandalf.stny.rr.com>
Date: Tue, 22 May 2012 10:50:29 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Avi Kivity <avi@...hat.com>
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 Tue, 2012-05-22 at 17:37 +0300, Avi Kivity wrote:
> >
> >
> > 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.
Thanks
>
>
> >
> > 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.
Yes, exceptions can only happen in the do_nmi area. There should not be
any breakpoints or page faults in the assembly code of the NMI handler.
Now another NMI may come in at any point here, but it will detect that
it is nested and return without doing anything (but telling this NMI to
repeat itself).
-- Steve
--
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