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

xen-devel

[Top] [All Lists]

[Xen-devel] another regression from IRQ handling changes

To: <xiantao.zhang@xxxxxxxxx>
Subject: [Xen-devel] another regression from IRQ handling changes
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: 2009年9月22日 09:18:58 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: 2009年9月22日 01:19:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
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).
Thoughts?
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: Re: [Xen-devel] Re: [PATCH] EPT: Flush running cpus, add mask to flush when scheduled in , Keir Fraser
Next by Date: Re: [Xen-devel] Re: [PATCH] EPT: Flush running cpus, add mask to flush when scheduled in , Keir Fraser
Previous by Thread: [Xen-devel] [pvops-dom0]Let PV ops guest could handle Machine Check trap , Ke, Liping
Next by Thread: Re: [Xen-devel] another regression from IRQ handling changes , Keir Fraser
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /