|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migr
To: |
Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them |
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Date: |
Sun, 08 May 2011 11:44:54 +1000 |
Cc: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "JBeulich@xxxxxxxxxx" <JBeulich@xxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx> |
Delivery-date: |
Sat, 07 May 2011 18:45:55 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<1304690697.26692.176.camel@xxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<625BA99ED14B2D499DC4E29D8138F1505C8ED7F7E3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1105061149330.3005@ionos> <625BA99ED14B2D499DC4E29D8138F1505C8ED7F962@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1105061505010.3005@ionos> <1304690697.26692.176.camel@xxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 |
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Tian, Kevin
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Stefano Stabellini
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Tian, Kevin
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Tian, Kevin
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Stefano Stabellini
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Thomas Gleixner
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Tian, Kevin
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Tian, Kevin
- [Xen-devel] RE: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them, Stefano Stabellini
|
|
|
|
|