WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] another regression from IRQ handling changes

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "xiantao.zhang@xxxxxxxxx" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] another regression from IRQ handling changes
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 22 Sep 2009 09:39:14 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 22 Sep 2009 01:39:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB8A49202000078000162D8@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco7XWi1G6tUKshKQMOsxwY5rLqi9gAAsE5b
Thread-topic: [Xen-devel] another regression from IRQ handling changes
User-agent: Microsoft-Entourage/12.20.0.090605
On 22/09/2009 09:18, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> An issue I had fixed a little while before your changes now appears to
> exist again (can't actively verify it due to lack of access to a sufficiently
> big system): While we now can handle more than 192 interrupt sources,
> those again are confined to the first 256 IO-APIC pins. We know,
> however, that there are systems with well over 300 pins (most of which
> are typically unused, and hence being able to "only" handle 192 interrupt
> sources doesn't really present a problem on these systems.
> 
> Clearly, handling of more than 256 (non-MSI) interrupt sources cannot
> be done without a kernel side change, since there needs to be a
> replacement for the 8-bit vector information conveyed through the
> kernel writes to the IO-APIC redirection table entries. However, up to
> 256 interrupt sources could easily be handled without kernel side
> change, by making PHYSDEVOP_alloc_irq_vector return a fake vector
> (rather than the unmodified irq that got passed in).

If it wasn't broken before, it was probably broken by Xiantao's follow-up
patch to fix NetBSD dom0 (at least as much as possible, to avoid a nasty
regression with NetBSD). What we probably need to do is have a 256-entry
dom0_vector_to_dom0_irq[] array, and allocate an entry from that for every
fresh irq we see at PHYSDEVOP_alloc_irq_vector. Then when the vector gets
passed back in on ioapic writes, we index into that array rather than using
naked rte.vector.

How does that sound?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel