public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Mikael Pettersson <mikpe@csd.uu.se>,
	linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection o
Date: Fri, 9 Feb 2001 14:04:33 MET-1	[thread overview]
Message-ID: <14FD47597566@vcnet.vc.cvut.cz> (raw)

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
                                            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/

             reply	other threads:[~2001-02-09 13:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-09 14:04 Petr Vandrovec [this message]
2001-02-09 20:59 ` [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  0:37 Petr Vandrovec
2001-02-09 12:10 ` 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=14FD47597566@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@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