linux-kernel - Re: [RFC Part4 v1 00/17] Refine support of non-PCI-compliant Message

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1411131410560.3935@nanos>
Date:	Thu, 13 Nov 2014 14:27:42 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Marc Zyngier <marc.zyngier@....com>
cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Randy Dunlap <rdunlap@...radead.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Yingjoe Chen <yingjoe.chen@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Joerg Roedel <joro@...tes.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Yijing Wang <wangyijing@...wei.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC Part4 v1 00/17] Refine support of non-PCI-compliant
 Message

On Thu, 13 Nov 2014, Marc Zyngier wrote:
> On 12/11/14 14:46, Thomas Gleixner wrote:
> > On Wed, 12 Nov 2014, Marc Zyngier wrote:
> >> This patch introduces two optionnal fields to the msi_chip structure:
> >> - a pointer to an irq domain, describing the MSI domain associated
> >>   with this msi_chip. To be populated with msi_create_irq_domain.
> >> - a domain_alloc_irqs() callback that has the same purpose as
> >>   arch_setup_msi_irqs(), with the above domain as an additional
> >>   parameter.
> >>
> >> If both of these fields are non-NULL, then domain_alloc_irqs() is
> >> called, bypassing the setup_irq callback. This allows the MSI driver
> >> to use the domain stacking feature without mandating core support in
> >> the architecture.
> > 
> > I'd rather have the callback in the irqdomain itself. Along with a
> > callback to free the interrupts.
> > 
> > AFAICT is msi_chip more or less a wrapper around the actual MSI irq
> > domain. So we rather move towards assigning irqdomain to the pci bus
> > and get rid of msi_chip instead of adding another level of obscure
> > indirection through msi_chip.
> 
> I can see that putting the irq domain at the bus level makes a lot of 
> sense (assuming nobody tries to have multiple MSI controllers per bus...).

That would be interesting :)
 
> So I'm starting with something like this:
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 640a1ec..07e50fc 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -41,6 +41,7 @@ struct irq_domain;
>  struct of_device_id;
>  struct irq_chip;
>  struct irq_data;
> +struct device;
>  
>  /* Number of irqs reserved for a legacy isa controller */
>  #define NUM_ISA_INTERRUPTS	16
> @@ -76,6 +77,10 @@ struct irq_domain_ops {
>  		     unsigned int nr_irqs);
>  	void (*activate)(struct irq_domain *d, struct irq_data *irq_data);
>  	void (*deactivate)(struct irq_domain *d, struct irq_data *irq_data);
> +	int (*prepare_alloc_irqs)(struct irq_domain *d, struct device *dev,
> +				  unsigned int nr_irqs, int type);
> +	int (*cleanup_free_irqs)(struct irq_domain *d, struct device *dev,
> +				 unsigned int virq, unsigned int nr_irqs);
>  #endif
>  };
> 
> How do you see this behaving? At the moment, I have the "prepare" callback
> directly calling into pci_msi_domain_alloc_irqs() so that the irqs get
> created, but I have the nagging feeling that it's not what you want... ;-)
> The main issue I can see is that if more than one domain in the stack
> implements that, who gets to call pci_msi_domain_alloc_irqs?
>
> If we try to decouple those two, there is a problem with the creation of
> the intermediate structure (the irq_alloc_info that's in Jiang's patches),
> as this is a arch/driver/whatever specific structure.

Hard to tell. I just saw Jiangs new series arrive and I want to look
at that first before muttering nonsense.

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/