From: Don Zickus <dzickus@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Peter Zijlstra <peterz@infradead.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking
Date: Wed, 7 Sep 2011 11:56:57 -0400 [thread overview]
Message-ID: <20110907155657.GX5795@redhat.com> (raw)
In-Reply-To: <4E678992.5050709@redhat.com>
On Wed, Sep 07, 2011 at 06:11:14PM +0300, Avi Kivity wrote:
> On 09/07/2011 04:44 PM, Don Zickus wrote:
> >>
> >> Is there a way to tell whether an NMI was internally or externally
> >> generated?
> >>
> >> I don't think so, especially as two or more NMIs can be coalesced.
> >> So any NMI received on this first cpu has to check the NMI reason
> >> port?
> >
> >Well we cheat and execute all the nmi handlers first. If they come back
> >as handled, we skip the check for the external NMI.
>
> And hope that no other NMI was generated while we're handling this
> one. It's a little... fragile?
No. If another NMI is generated while we are processing the current one
it should get latched. Upon completion of the current one, the cpu should
jump right back into the nmi exception routine again. The only downside
is when multiple NMIs come in during the processing of the current one.
Only one can be latched, so the others get dropped. But we are addressing
that.
Cheers,
Don
>
> >But you are right, other than checking the reason port, there isn't a way
> >to determine if an NMI is internally or externally generated.
>
> Ouch.
>
> >
> >>
> >> >>
> >> >> But on the other hand, I don't really care if you can say that this path
> >> >> will never be called in a virtual machine.
> >> >
> >> >Does virtual machines support hot remove of cpus? Probably not
> >> >considering bare-metal barely supports it.
> >> >
> >>
> >> They do.
> >
> >But vcpus probably don't have the notion of a bsp cpu, so perhaps virtual
> >machines can get away with it easier? (I don't know enough about the hot
> >cpu remove code to really explain it, just enough to know it can cause
> >problems and people are trying to address it).
> >
>
> The concept of a bsp exists in exactly the same way as on real hardware.
>
> --
> error compiling committee.c: too many arguments to function
>
next prev parent reply other threads:[~2011-09-07 15:56 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-02 0:54 [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 01/13] x86/spinlocks: replace pv spinlocks with pv ticketlocks Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 02/13] x86/ticketlock: collapse a layer of functions Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 03/13] xen/pvticketlock: Xen implementation for PV ticket locks Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 04/13] x86/pvticketlock: use callee-save for lock_spinning Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 05/13] x86/ticketlocks: when paravirtualizing ticket locks, increment by 2 Jeremy Fitzhardinge
2011-09-02 0:54 ` [PATCH 06/13] x86/ticketlock: add slowpath logic Jeremy Fitzhardinge
2011-09-02 18:46 ` Eric Northup
2011-09-02 19:32 ` Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 07/13] x86/ticketlocks: tidy up __ticket_unlock_kick() Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking Jeremy Fitzhardinge
2011-09-02 14:47 ` Peter Zijlstra
2011-09-02 19:29 ` Jeremy Fitzhardinge
2011-09-02 20:47 ` Peter Zijlstra
2011-09-02 21:50 ` Jeremy Fitzhardinge
2011-09-02 22:37 ` Peter Zijlstra
2011-09-02 23:14 ` Andi Kleen
2011-09-05 11:52 ` Stefano Stabellini
2011-09-05 12:05 ` Avi Kivity
2011-09-06 15:14 ` Don Zickus
2011-09-06 18:07 ` Jeremy Fitzhardinge
2011-09-06 18:27 ` Don Zickus
2011-09-06 18:50 ` Jeremy Fitzhardinge
2011-09-07 4:13 ` Avi Kivity
2011-09-07 13:44 ` Don Zickus
2011-09-07 15:11 ` Avi Kivity
2011-09-07 15:56 ` Don Zickus [this message]
2011-09-07 16:25 ` Avi Kivity
2011-09-07 16:52 ` Don Zickus
2011-09-07 17:09 ` Avi Kivity
2011-09-07 17:17 ` Jeremy Fitzhardinge
2011-09-07 17:41 ` Avi Kivity
2011-09-07 19:09 ` Jeremy Fitzhardinge
2011-09-08 7:51 ` Avi Kivity
2011-09-08 17:29 ` Jeremy Fitzhardinge
2011-09-11 9:59 ` Avi Kivity
2011-09-07 17:21 ` Don Zickus
2011-09-07 17:41 ` Avi Kivity
2011-09-13 18:40 ` Don Zickus
2011-09-13 19:03 ` Andi Kleen
2011-09-13 19:21 ` Don Zickus
2011-09-13 19:58 ` Andi Kleen
2011-09-13 20:53 ` Don Zickus
2011-09-13 21:04 ` Andi Kleen
2011-09-14 7:00 ` Avi Kivity
2011-09-14 12:49 ` Don Zickus
2011-09-14 14:49 ` Andi Kleen
2011-09-14 15:01 ` Avi Kivity
2011-09-14 17:28 ` Andi Kleen
2011-09-14 19:26 ` Avi Kivity
2011-09-14 19:34 ` Andi Kleen
2011-09-14 19:56 ` Avi Kivity
2011-09-13 19:27 ` Don Zickus
2011-09-02 0:55 ` [PATCH 09/13] x86/pvticketlocks: we only need to kick if there's waiters Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 10/13] xen/pvticket: allow interrupts to be enabled while blocking Jeremy Fitzhardinge
2011-09-02 14:48 ` Peter Zijlstra
2011-09-02 19:30 ` Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 11/13] x86/ticketlock: only do kick after doing unlock Jeremy Fitzhardinge
2011-09-02 14:49 ` Peter Zijlstra
2011-09-02 19:34 ` Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 12/13] x86/pvticketlock: make sure unlock_kick pvop call is inlined Jeremy Fitzhardinge
2011-09-02 0:55 ` [PATCH 13/13] x86/pvticketlock: use __ticket_t for pvop args Jeremy Fitzhardinge
2011-09-02 11:22 ` [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks Stefano Stabellini
2011-09-06 19:33 ` Jeremy Fitzhardinge
2011-09-02 15:38 ` Linus Torvalds
2011-09-02 20:07 ` Jeremy Fitzhardinge
2011-09-02 20:27 ` Linus Torvalds
2011-09-02 21:42 ` Jeremy Fitzhardinge
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=20110907155657.GX5795@redhat.com \
--to=dzickus@redhat.com \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=jeremy@goop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=npiggin@kernel.dk \
--cc=peterz@infradead.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.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;
as well as URLs for NNTP newsgroup(s).