From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"Tian, Kevin" <kevin.tian@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"JBeulich@novell.com" <JBeulich@novell.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
Date: Sun, 08 May 2011 11:44:54 +1000 [thread overview]
Message-ID: <4DC5F596.4090303@goop.org> (raw)
In-Reply-To: <1304690697.26692.176.camel@zakaz.uk.xensource.com>
On 05/07/2011 12:04 AM, Ian Campbell wrote:
> I'm not really sure why these can't just be an evtchn without an
> associated IRQ since it doesn't really have any interrupt-like
> semantics. Perhaps just a general desire to keep event channels
> abstracted into the core Xen event subsystem with IRQs as the public
> facing API? Jeremy?
It doesn't really need to be an irq. The main reason was so that it
would appear in /proc/interrupts so I could use the counter as a "number
of times a spinlock was kicked" counter. That could be exposed in some
other way if being part of the interrupt infrastructure brings too much
baggage with it.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"JBeulich@novell.com" <JBeulich@novell.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
Date: Sun, 08 May 2011 11:44:54 +1000 [thread overview]
Message-ID: <4DC5F596.4090303@goop.org> (raw)
In-Reply-To: <1304690697.26692.176.camel@zakaz.uk.xensource.com>
On 05/07/2011 12:04 AM, Ian Campbell wrote:
> I'm not really sure why these can't just be an evtchn without an
> associated IRQ since it doesn't really have any interrupt-like
> semantics. Perhaps just a general desire to keep event channels
> abstracted into the core Xen event subsystem with IRQs as the public
> facing API? Jeremy?
It doesn't really need to be an irq. The main reason was so that it
would appear in /proc/interrupts so I could use the counter as a "number
of times a spinlock was kicked" counter. That could be exposed in some
other way if being part of the interrupt infrastructure brings too much
baggage with it.
J
next prev parent reply other threads:[~2011-05-08 1:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 6:43 [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them Tian, Kevin
2011-05-06 9:59 ` Thomas Gleixner
2011-05-06 12:54 ` Tian, Kevin
2011-05-06 12:54 ` Tian, Kevin
2011-05-06 13:14 ` [Xen-devel] " Tian, Kevin
2011-05-06 13:24 ` Thomas Gleixner
2011-05-06 14:04 ` Ian Campbell
2011-05-08 1:44 ` Jeremy Fitzhardinge [this message]
2011-05-08 1:44 ` Jeremy Fitzhardinge
2011-05-09 0:44 ` Tian, Kevin
2011-05-09 0:44 ` Tian, Kevin
2011-05-09 1:45 ` Jeremy Fitzhardinge
2011-05-09 1:45 ` Jeremy Fitzhardinge
2011-05-06 14:28 ` Stefano Stabellini
2011-05-06 14:28 ` Stefano Stabellini
2011-05-06 21:43 ` Tian, Kevin
2011-05-09 2:11 ` Tian, Kevin
2011-05-09 12:02 ` Stefano Stabellini
2011-05-09 12:36 ` Thomas Gleixner
2011-05-10 3:24 ` Tian, Kevin
2011-05-18 23:49 ` Tian, Kevin
2011-05-18 23:49 ` Tian, Kevin
2011-05-19 12:08 ` Stefano Stabellini
2011-05-19 16:18 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-05-19 16:18 ` Konrad Rzeszutek Wilk
2011-08-29 4:15 ` [regression] Ideapad S10-3 does not wake up from suspend (Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them) Jonathan Nieder
2011-08-31 1:04 ` Dave Hansen
2011-08-31 8:22 ` Jonathan Nieder
2011-09-02 3:01 ` Serge E. Hallyn
2011-09-01 6:24 ` Tian, Kevin
2011-09-01 6:24 ` Tian, Kevin
2012-05-12 23:13 ` [regression] Ideapad S10-3 does not wake up from suspend Jonathan Nieder
2012-05-13 1:22 ` Lars Boegild Thomsen
2012-07-15 23:24 ` Jonathan Nieder
2012-04-15 14:06 ` Jonathan Nieder
2012-04-16 18:05 ` Robert Scott
2012-04-17 2:04 ` Jonathan Nieder
2012-04-18 10:03 ` Lars Boegild Thomsen
2012-04-22 16:34 ` [Xen-devel] " Pasi Kärkkäinen
2012-04-21 13:14 ` Robert Scott
2012-05-06 12:44 ` Robert Scott
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=4DC5F596.4090303@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Campbell@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=hpa@zytor.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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.