linux-kernel - Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains

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]

Date:	Mon, 29 Sep 2014 17:53:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Abel <wuyun.wu@...wei.com>
cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	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>,
	Borislav Petkov <bp@...en8.de>,
	Grant Likely <grant.likely@...aro.org>,
	Marc Zyngier <marc.zyngier@....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>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support
 hierarchy irqdomains

On Mon, 29 Sep 2014, Abel wrote:
> On 2014/9/26 22:02, Jiang Liu wrote:
> > +static void irq_domain_free_descs(unsigned int virq, unsigned int nr_irqs)
> > +{
> > +	unsigned int i;
> > +
> > +	for (i = 0; i < nr_irqs; i++)
> > +		irq_free_desc(virq + i);
> > +}
> 
> I am not sure why this function is needed, since it works in the exact same
> way as irq_free_descs(virq, nr_irqs).

Indeed.
 
> I've been through your patches and noticed that the only domain
> which does not call irq_domain_alloc_irqs_parent() is
> x86_vector_domain. And this makes sense *if* we already knew which
> domain is the nearest one to the CPU.

Right, and in case of x86 the vector domain _IS_ the one which is
always the nearest one to the cpu.

> But I don't think a well implemented device driver should assume
> itself be in a particular position of the interrupt delivery path.

The device driver has no knowledge of this. The irq domain driver
definitely has to know to some extent.

> Actually it should be guaranteed by the core infrastructure that all
> the domains in the interrupt delivery path should allocate a
> hardware interrupt for the interrupt source.

Well, that's what we do. We allocate down the irq domain hierarchy. If
one level fails the whole operation fails.

> And besides the comments/questions I mentioned above, I am also curious about
> how the chained interrupts been processed.
> 
> Let's take a 3-level-chained-domains for example.
> Given 3 interrupt controllers A, B and C, and the interrupt delivery path is:
> 
> DEV -> A -> B -> C -> CPU
> 
> After the hierarchy irqdomains are established, the unique linux interrupt of
> DEV will be mapped with a hardware interrupt in each domain:
> 
> DomainA: HWIRQ_A => VIRQ_DEV
> DomainB: HWIRQ_B => VIRQ_DEV
> DomainC: HWIRQ_C => VIRQ_DEV
> 
> When the DEV triggered an interrupt signal, the CPU will acknowledge HWIRQ_C,

Not necessarily. The CPU will process HWIRQ_C. The acknowledge
mechanism depends on the implementation details of the hierarchy.

> and then irq_find_mapping(DomainC, HWIRQ_C) will be called to get the linux
> interrupt VIRQ_DEV, and after the handler of the VIRQ_DEV has been processed,
> the interrupt will end with the level (if have) uncleared on B, which will
> result in the interrupt of DEV cannot be processed again.
> 
> Or is there anything I misunderstand?

This heavily depends on the properties of the stacked domains.

It depends on the hardware requirements and the implementation of
domain A and B how this is handled.

It might be sufficient to have the following code in the irq_ack()
callback of domain A:

irq_ack_A(struct irq_data *d)
{
	ack_hw_A();
}

Another HW or stacking scenario requires

irq_ack_A(struct irq_data *d)
{
	ack_hw_A();
	ack_parent();
}

where ack_parent() does:

      if (d->parent_data)
      	 d->parent_data->chip->ack(d->parent_data);

and ack_hw_A() can be anything from a nop to some more or less complex
hw access.

So we cannot define upfront how deep an ack/mask/unmask/... has to be
propagated down the chain. This needs a careful consideration in terms
of functionality and we want to be able to do performance shortcuts as
well.

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/