From: Peter Zijlstra <peterz@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@kernel.dk>, Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Xen Devel <xen-devel@lists.xensource.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking
Date: Sat, 03 Sep 2011 00:37:07 +0200 [thread overview]
Message-ID: <1315003027.10110.2.camel@twins> (raw)
In-Reply-To: <4E614FBD.2030509@goop.org>
On Fri, 2011-09-02 at 14:50 -0700, Jeremy Fitzhardinge wrote:
> On 09/02/2011 01:47 PM, Peter Zijlstra wrote:
> > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote:
> >>> I know that its generally considered bad form, but there's at least one
> >>> spinlock that's only taken from NMI context and thus hasn't got any
> >>> deadlock potential.
> >> Which one?
> > arch/x86/kernel/traps.c:nmi_reason_lock
> >
> > It serializes NMI access to the NMI reason port across CPUs.
>
> Ah, OK. Well, that will never happen in a PV Xen guest. But PV
> ticketlocks are equally applicable to an HVM Xen domain (and KVM guest),
> so I guess there's at least some chance there could be a virtual
> emulated NMI. Maybe? Does qemu do that kind of thing?
Afaik qemu/kvm can do the whole NMI thing, yes.
> But, erm, does that even make sense? I'm assuming the NMI reason port
> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and
> there's only a single reason port, then doesn't that mean that either 1)
> they all got the NMI for the same reason, or 2) having a single port is
> inherently racy? How does the locking actually work there?
I really wouldn't know, the whole NMI thing is a bit of a trainwreck
architecturally. Maybe the x86 maintainers or Linus knows more on this
aspect of it.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Nick Piggin <npiggin@kernel.dk>, KVM <kvm@vger.kernel.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>, Avi Kivity <avi@redhat.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
the
Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking
Date: Sat, 03 Sep 2011 00:37:07 +0200 [thread overview]
Message-ID: <1315003027.10110.2.camel@twins> (raw)
In-Reply-To: <4E614FBD.2030509@goop.org>
On Fri, 2011-09-02 at 14:50 -0700, Jeremy Fitzhardinge wrote:
> On 09/02/2011 01:47 PM, Peter Zijlstra wrote:
> > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote:
> >>> I know that its generally considered bad form, but there's at least one
> >>> spinlock that's only taken from NMI context and thus hasn't got any
> >>> deadlock potential.
> >> Which one?
> > arch/x86/kernel/traps.c:nmi_reason_lock
> >
> > It serializes NMI access to the NMI reason port across CPUs.
>
> Ah, OK. Well, that will never happen in a PV Xen guest. But PV
> ticketlocks are equally applicable to an HVM Xen domain (and KVM guest),
> so I guess there's at least some chance there could be a virtual
> emulated NMI. Maybe? Does qemu do that kind of thing?
Afaik qemu/kvm can do the whole NMI thing, yes.
> But, erm, does that even make sense? I'm assuming the NMI reason port
> tells the CPU why it got an NMI. If multiple CPUs can get NMIs and
> there's only a single reason port, then doesn't that mean that either 1)
> they all got the NMI for the same reason, or 2) having a single port is
> inherently racy? How does the locking actually work there?
I really wouldn't know, the whole NMI thing is a bit of a trainwreck
architecturally. Maybe the x86 maintainers or Linus knows more on this
aspect of it.
next prev parent reply other threads:[~2011-09-02 22:41 UTC|newest]
Thread overview: 86+ 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 ` 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 ` 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 19:29 ` Jeremy Fitzhardinge
2011-09-02 20:47 ` Peter Zijlstra
2011-09-02 20:47 ` Peter Zijlstra
2011-09-02 21:50 ` Jeremy Fitzhardinge
2011-09-02 22:37 ` Peter Zijlstra [this message]
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-06 18:50 ` Jeremy Fitzhardinge
2011-09-07 4:13 ` Avi Kivity
2011-09-07 13:44 ` Don Zickus
2011-09-07 13:44 ` Don Zickus
2011-09-07 15:11 ` Avi Kivity
2011-09-07 15:11 ` Avi Kivity
2011-09-07 15:56 ` Don Zickus
2011-09-07 15:56 ` Don Zickus
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-08 17:29 ` Jeremy Fitzhardinge
2011-09-11 9:59 ` Avi Kivity
2011-09-11 9:59 ` Avi Kivity
2011-09-07 17:21 ` Don Zickus
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: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 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 17:28 ` Andi Kleen
2011-09-14 19:26 ` Avi Kivity
2011-09-14 19:34 ` Andi Kleen
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 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-02 11:22 ` 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=1315003027.10110.2.camel@twins \
--to=peterz@infradead.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.