This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migr

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 09 May 2011 11:45:13 +1000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "JBeulich@xxxxxxxxxx" <JBeulich@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Delivery-date: Sun, 08 May 2011 18:46:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F1505C8ED7FAA0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <4DC5F596.4090303@xxxxxxxx> <625BA99ED14B2D499DC4E29D8138F1505C8ED7FAA0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10
On 05/09/2011 10:44 AM, Tian, Kevin wrote:
>> 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.
> Perhaps we don't need an irq binding here. Just like a local APIC interrupt
> source which only needs vector. Somehow the virq or vipi concept in Xen
> context is similar.

An event channel is logically equivalent to a vector, so that would make
sense.  We currently allocate irqs for cross-cpu call and reschedule
event channels, whereas native x86 simply uses a naked vector for
those.  But they are real interrupts, so an irq at least makes some
logical sense in those cases.

For spinlocks, the event channel is more like a usermode-level signal
which is always blocked and only ever tested with sigsuspend (or is it
sigpoll?  something like that).


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>