From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: linux-kernel@vger.kernel.org, marco@ds2.pg.gda.pl, mingo@redhat.com
Subject: Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection o
Date: Fri, 9 Feb 2001 00:37:40 MET-1 [thread overview]
Message-ID: <14EFD2E43005@vcnet.vc.cvut.cz> (raw)
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
vandrove@vc.cvut.cz
-
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/
next reply other threads:[~2001-02-08 23:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-09 0:37 Petr Vandrovec [this message]
2001-02-09 12:10 ` [PATCH] Re: UP APIC reenabling vs. cpu type detection o Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2001-02-09 14:04 Petr Vandrovec
2001-02-09 20:59 ` Maciej W. Rozycki
2001-02-08 23:06 Mikael Pettersson
2001-02-09 12:06 ` Maciej W. Rozycki
2001-02-08 12:32 Petr Vandrovec
2001-02-08 16:05 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14EFD2E43005@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=marco@ds2.pg.gda.pl \
--cc=mikpe@csd.uu.se \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox