linux-kernel - Re: [patch 03/32] genirq: Provide generic hwirq allocation facility

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1405081505420.6261@ionos.tec.linutronix.de>
Date:	Thu, 8 May 2014 15:12:48 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Grant Likely <grant.likely@...retlab.ca>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Anvin <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [patch 03/32] genirq: Provide generic hwirq allocation
 facility

On Thu, 8 May 2014, Grant Likely wrote:
> On Wed, 07 May 2014 15:44:05 -0000, Thomas Gleixner <tglx@...utronix.de> wrote:
> > +EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
> 
> Okay, so regarding this and irq_domains, I think the functionality
> overlaps and irq_domain conversion wouldn't directly use this API. I
> could see two ways that it would be wired up in an irq_domain
> conversion...
> 
> 1) use an irq_domain to represent the root of the interrupt tree and be
> responsible for all of the hardware irqs. Child interrupt controllers
> would allocate a hwirq from the root irq_domain and program itself
> accordingly. This approach would either not use this API, or make it
> entirely internal to the root irq_domain.
> 
> 2) Use this API as the root of the interrupt tree and make first level
> of child interrupt controllers use this API to allocate HWIRQs to use
> for their irq outputs.
> 
> Most of the platforms using irq_domain now fall in the first category,
> which I think makes the most sense. Any platform like x86 that has
> multiple hwirq vectors and the option of per-cpu vectors would be best
> to keep all of that detail in one place. We could add a cpumask variant
> to the irqdomain APIs, and add a stock implementation of an allocator
> that can intelligently allocate when cpumasks are used.

When we have a root domain which handles the vector matrix, then we
can put sub domains on top which handle the various irq chips (PIC,
IOAPIC, MSI ....).

So that will need some cpumask support in irq domains, but that's not
a bad thing in general. Even ARM might get some benefit from for the
SPIs.

Thanks,

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