Eric W. Biederman wrote:
quoted text
>> I'm still interested in making Xen's event channel-based interrupts fit better
>> into the rest of the interrupt handling scheme.  In particular, event channels
>> map very closely to the x86-64 notion of a vector.  There's 1024 of them per
>> domain, and each is bound to a cpu.  At the moment, I map them to irqs, which
>> means that I need to allocate around 5-6 irqs per cpu, which makes everything
>> very cluttered.  I'd like to map event channels to vectors, and then map vectors
>> to (irq,cpu) tuples.
>>     
>
> Uh....  I'm not certain this applies.
>   

No, but, hey, it's a hook.

quoted text
>> From what I've seen this is exactly how x86-64 currently has things set up, and
>> I'm interested in making sure that 32-bit does the same thing.
>>     
>
> Yes. x86_32 needs work to get cleaned up.
>
> The architecture on x86_64 is as follows.
>
> We have interrupt sources:  GSIs in the case of acpi.
> We have linux interupts:  something with an irq number.
>
> Vectors are an internal implementation detail.
>
> I don't know if your event channels more closely resemble interrupt sources or internal
> implementation details.  If they are an implementation detail that interrupt sources
> just flow through we should hide them like we do vectors.  If event channels actually are
> the sources of interrupts we should do something different.
>   

They're an interrupt source, I guess.  They need to be behind some layer 
of indirection because they can be reassigned at arbitrary times (like 
suspend/resume, or if the backend driver just decided to disconnect 
itself), and so they need to get rebound to at least the same irq.

quoted text
>> I'm also interested in having vectors being sourced from multiple interrupt
>> controllers.  So, some vectors would be sourced from APICs, and other are
>> sourced from event channels.  This would be useful for Xen domains which have
>> direct access to hardware (ie, the dom0 control domain in the short term, and
>> disaggregated driver domains later on), and fully emulated domains which have
>> paravirtual drivers.
>>     
>
> Generally easy except for the disparate methods of catching interrupts.
>   

Catching in what sense?  I assume the interrupt gets raised in some 
source-specific way, and then passed into a generic layer where it 
eventually gets matched with an appropriate handler.  I'm sure there's 
some subtlety I'm missing.

quoted text
>> I haven't studied the current code to see if this notion already exists or not.
>>
>> While the APIC interrupt model is the most architecturally important for the x86
>> platform, I'd like to make sure we don't build in the assumption that it's the
>> *only* interrupt model.
>>     
>
> Well with iommus starting to show up in our irq paths it looks we are going to get
> a lot of diversity.
>
> Eric
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/