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: Mon, 19 May 2014 23:04:22 +0900 (JST) From: Thomas Gleixner <tglx@...utronix.de> To: Jiang Liu <jiang.liu@...ux.intel.com> cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Bjorn Helgaas <bhelgaas@...gle.com>, Randy Dunlap <rdunlap@...radead.org>, Yinghai Lu <yinghai@...nel.org>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>, Tony Luck <tony.luck@...el.com>, Joerg Roedel <joro@...tes.org>, Paul Gortmaker <paul.gortmaker@...driver.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, x86@...nel.org, LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org, sfi-devel@...plefirmware.org, Grant Likely <grant.likely@...aro.org> Subject: Re: [RFC Patch Part1 V1 00/30] use irqdomain to dynamically allocate IRQ for IOAPIC pin Jiang, On Sun, 18 May 2014, Jiang Liu wrote: > On 2014/5/16 23:28, Thomas Gleixner wrote: > >> Patch 1-17 are trivial code improvements, bugfixes and preparation. > > > > Can you please move the bugfixes before the other changes, so we can > > pick them up independently from the outcome? > Sure, will reorder the patch set in next version. Thanks. > > > >> Patch 18-24 enable basic irqdomain support and IRQ number dynamic > >> allocation. > >> > >> Patch 25-29 consoldate the way to program IOAPIC pins by using > >> irqdomain map() interface. > >> > >> Patch 30 cleans up unused interfaces and functions in IOAPIC driver. > >> > >> Tests and comments are warmly welcomed! > > > > I like the general approach, but we have now a mixture of legacy irq > > handling and irq domains. We really want to cleanup the legacy PIC no > > ioapic case as well. That will cleanup the code further. > > > > The other thing we discussed here: https://lkml.org/lkml/2014/5/7/901 > > in several places of the thread is to move the vector allocation into > > a irqdomain with a generic matrix allocator as well. We have other use > > cases for this as well. It would be nice if you could look at that as > > well. > I have read through the thread, it's an interesting discussion. > > After my first thought, I have gotten some ideas about how to reorganize > x86 interrupt subsystem using irqdomain framework based on ideas from > the thread. Because I'm newbie to interrupt subsystem, I will share my > naive ideas first and RFC for whether it's the right direction. > > We may build hierarchy irqdomains as below for x86, > [IOAPIC] [MSI/MSI-x] [HPET] [DMAR] [Legacy] > | | | | | > v v v | | > [ Remapping ] | | > | | | > v v v > [ Root/vector ] > > The remapping domain is optional and used to support IRQ remapping unit. > We abstract remapping entry as hardware interrupt pin and will extend > irqdomain interface to support automatic assignment of hardware > interrupt pin. > > The root/vector domain is used to manage per CPU vector numbers and > CPU vector is abstracted as hardware interrupt pin. It will support > automatic vector number assignment. To support root/vector domain, > we need to extend irqdomain interface to pass down information > or constraints about the IRQ allocation. > > So how about following extension to current irqdomain interfaces? I cc'ed Grant Likely. He might have some opinion on this as well. > diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h > index c983ed18c332..2fd7e50cde32 100644 > --- a/include/linux/irqdomain.h > +++ b/include/linux/irqdomain.h > @@ -42,6 +42,13 @@ struct of_device_id; > /* Number of irqs reserved for a legacy isa controller */ > #define NUM_ISA_INTERRUPTS 16 > > +#define IRQDOMAIN_AUTO_ASSIGN_HWIRQ ULONG_MAX > +#ifdef arch_irq_alloc_info_t > +typedef arch_irq_alloc_info_t irq_alloc_info_t; > +#else > +typedef void irq_alloc_info_t; > +#endif > > /** > * struct irq_domain_ops - Methods for irq_domain objects > * @match: Match an interrupt controller device node to a host, returns > @@ -59,7 +66,11 @@ struct of_device_id; > */ > struct irq_domain_ops { > int (*match)(struct irq_domain *d, struct device_node *node); > - int (*map)(struct irq_domain *d, unsigned int virq, > irq_hw_number_t hw); > + int (*alloc)(struct irq_domain *d, irq_hw_number_t hw, > + irq_alloc_info_t *info); > + int (*free)(struct irq_domain *d, unsigned int virq); > + int (*map)(struct irq_domain *d, unsigned int virq, > irq_hw_number_t hw, > + irq_alloc_info_t *info); > void (*unmap)(struct irq_domain *d, unsigned int virq); > int (*xlate)(struct irq_domain *d, struct device_node *node, > const u32 *intspec, unsigned int intsize, > > alloc()/free() interfaces will be used allocate/free IRQ from parent > domain. And irq_alloc_info_t structure is used to host parameters > and constraints for IRQ allocation. > > For x86, irq_alloc_info_t structure will be used to host CPU mask, > device pointer, IOAPIC pin attributes, NUMA node info etc. Do we really need to hand all of this down? 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/
Powered by blists - more mailing lists