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

[Petr Vandrovec]

On  9 Feb 01 at 0:06, Mikael Pettersson wrote:
> On Thu, 8 Feb 2001 12:32:01 MET-1, Petr Vandrovec wrote:
> 
> >I have another question for UP APIC NMI: As I reported some time ago,
> >if performance counters overflow when LVTPC has 'disabled' bit set,
> >NMI is lost forever. This causes problems with VMware - it has to
> >disable NMI deliveries during CR3 (memory mapping) switching, and if 
> >performance counter overflows at that time, you'll not receive another 
> >NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz 
> >Athlon. And 410 * 65536 seconds on idle Athlon)...
> 
> How long do you need to keep NMIs blocked?

Under some circumstances until `real' (usually timer) interrupt happens :-(
It is up to 10ms (on ia32).
 
> The watchdog (re-)initialises the perfctr to a negative value, but
> after overflow the counter will read as positive. (You'll have to
> use rdpmc() and sign-extend the low bits of the high word.)
> So if, after your critical section, the counter reads as positive
> you know that you missed an NMI. In that case, just write the restart
> value to the counter.
> 
> Alternatively, if you block the NMI watchdog for a long time, say a
> couple of thousand cycles or more, you can unconditionally restart it.

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().
                                                    Petr Vandrovec
                                                    [e-mail]