Re: number of interrupt sources limit

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/06/01 4:09, Manuel Bouyer wrote:
> Hello,
> actually, the number of interrupt sources per CPU (but all peripheral
> interrupts are routed to the BSP) is limited to 32. Is this considered
> enough for modern x86 ?

As you may know, *hardware* interrupt is limited to 25, because upper
7 bit of ci_pending bitmask are used for software management. That is,
LIR_IPI, LIR_TIMER, and so on use those bits. Please see
sys/arch/x86/include/interdefs.h
    https://nxr.netbsd.org/xref/src/sys/arch/x86/include/intrdefs.h#24

> It's definitively not enough for Xen (either dom0 or domU), which is
> why Xen uses a different vector/spl implementation. As I'm working
> on PV drivers for HVM guests it's time to revisit this.
> I have two options:
> a)  do not touch the x86 native spl implementation, and use a special
>     vector for handling Xen events. The event vector will add
>     bits to the ci_ipending mask so that it's called again on spllower.
>     x86 bare metal is untouched but Xen will be less efficient.
> 
> b)  expand ci_ipending to a two-level bitmask, which would give us
>     1024 (32*32) interrupt source. This would allow to share
>     more code with xen, at the expense of a few more instructions in
>     spllower() and in interrupt path on bare metal, and some more
>     32bit words in cpu_info.
> 
> Any red herring with one or the other solution before I start coding ?

b) is excellent idea, but I think it will be hard work. FreeBSD/amd64
uses such two level interrupt mechanism. Once, I tried to port the 
implementation to NetBSD, however I give up because of lack of lapic
and ioapic implementations. And then, I found NetBSD can assign
interrupts to AP (other than BSP), so I change my mind not to increase
interrupts number of one CPU but to use multiple CPUs.

Anyway, I think you should select the way which just satisfy your need.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>