2001-02-09 13:07:55

by Petr Vandrovec

[permalink] [raw]
Subject: Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection o

On 9 Feb 01 at 13:10, Maciej W. Rozycki wrote:
> On Fri, 9 Feb 2001, Petr Vandrovec wrote:
>
> > Unfortunately both these ways needs intimate knowledge of how UP NMI
> > watchdog works in each kernel, and it is incompatible with other
> > perfctr uses. Probably I'll switch perfctr delivery to some real
> > maskable interrupt while VMware VM owns CPU - if it is possible.
> > Then interrupt should be still pending after VM does __sti().
>
> 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.
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.

If you have any idea how it can be done with NMI unmasked all the way
around...
Thanks,
Petr Vandrovec
[email protected]


2001-02-09 21:02:47

by Maciej W. Rozycki

[permalink] [raw]
Subject: Re: [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: [email protected], PGP key available +