lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jul 2016 14:54:36 +0100 From: Marc Zyngier <marc.zyngier@....com> To: Sebastian Frias <sf84@...oste.net>, Thomas Gleixner <tglx@...utronix.de> Cc: Jason Cooper <jason@...edaemon.net>, Mason <slash.tmp@...e.fr>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router On 06/07/16 11:49, Sebastian Frias wrote: > Hi, > > On 07/06/2016 11:30 AM, Thomas Gleixner wrote: >> On Wed, 6 Jul 2016, Marc Zyngier wrote: >>> On 05/07/16 20:24, Thomas Gleixner wrote: >>>> On Tue, 5 Jul 2016, Marc Zyngier wrote: >>>>> Hardcoded? No way. You simply implement a route allocator in your >>>>> driver, assigning them as needed. And yes, if you have more than 24 >>>>> interrupts, they get muxed. >>>> >>>> There is one caveat though. Under some circumstances (think RT) you want to >>>> configure which interrupts get muxed and which not. We really should have that >>>> option, but yes for anything which has less than 24 autorouting is the way to >>>> go. >>> >>> Good point. I can see two possibilities for that: >>> >>> - either we describe this DT with some form of hint, indicating what are >>> the inputs that can be muxed to a single output. Easy, but the DT guys >>> are going to throw rocks at me for being Linux-specific. >> >> That's not necessarily Linux specific. The problem arises with any other OS as >> well. >> >>> - or we have a way to express QoS in the irq subsystem, and a driver can >>> request an interrupt with a "make it fast" flag. Of course, everybody >>> and his dog are going to ask for it, and we're back to square one. >> >> That and the driver does not know about the particular application >> scenario/system configuration. >> >>> Do we have a way to detect which interrupt is more likely to be >>> sensitive to muxing? My hunch is that if it is requested with >>> IRQF_SHARED, then it is effectively muxable. Thoughts? >> >> That's too late. request_irq happens _after_ the interrupt is set up and the >> routing established. >> > > What about using 3 values for the interrupt description like the GIC does? > When connecting to the GIC we say "interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;" > If devices using this driver (the one from the RFC) requested the interrupt like: > "interrupts = <0 38 IRQ_TYPE_LEVEL_HIGH>;" > "interrupts = <2 27 IRQ_TYPE_LEVEL_HIGH>;" > etc. > with the first field being the "group", then the driver could create a domain > for the device's IRQ (or associate it to an existing one if it has already been > created). It would thus serve as a hint on how to create domains and how to > share IRQs into the same line (domain). > > I guess I can get such information from the .translate and .alloc callbacks > from a newly created domain hierarchy attached to the GIC, right? This wouldn't work. You need to instantiate the domains long before you've parsed a single interrupt specifier, otherwise you don't know where to allocate it from. Thanks, M. -- Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists