lkml.org 
[lkml]   [2001]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: UP APIC reenabling vs. cpu type detection o
On Fri, 9 Feb 2001, Petr Vandrovec wrote:

> > Why do you need to mask NMI at all?
>
> Because of you must provide some function which handles NMI, and as
> you cannot switch IDT and CR3 atomically together, NMI handler has
> to be on same address in both address spaces - at least temporary.

Can't it be?

> And in addition NMI handler in VM would have to switch address spaces
> back, execute NMI handler, and return CPU/MMU back to previous state -
> which may be just in the middle of normal VM<->Linux transition, so
> this context switching cannot use any global variable, it must
> save complete CPU/MMU state on stack. And it must not use any spinlock.

Do you need to pass NMIs to VM at all? NMIs as defined by the PC/AT
architecture are delivered as a result of memory parity errors or ISA
IOCHK errors. Is that functionality really needed in VM?

> If you have any idea how it can be done with NMI unmasked all the way
> around...

It depends on the application -- you may avoid problems by careful coding
and a nested NMI will never happen -- the CPU masks the NMI line
internally, from accepting an NMI till a subsequent iret.

--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.045 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site