All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abel <wuyun.wu@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Yinghai Lu <yinghai@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tony Luck <tony.luck@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains
Date: Tue, 30 Sep 2014 18:56:30 +0800	[thread overview]
Message-ID: <542A8C5E.3040901@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1409291707410.22082@ionos.tec.linutronix.de>

Hi Thomas,
On 2014/9/29 23:53, Thomas Gleixner wrote:

> On Mon, 29 Sep 2014, Abel wrote:
>> 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.

Yes, I know that. :)
What I meant is... (please see below)

> 
>> 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.

Actually the core infrastructure just calls domain->ops->alloc() which is
the one who really guarantees it by calling irq_domain_alloc_irqs_parent().
I think it's enough for a particular domain to pick a hwirq from itself for
that linux irq, and need not to care about its parent.
What I suggest is something like:

for (iter = domain; iter; iter = iter->parent) {
	ret = iter->ops->alloc(iter, virq, nr_irqs, arg);
	if (ret < 0) {
		mutex_unlock(&irq_domain_mutex);
		goto out_free_irq_data;
	}
}

in this way, the core infrastructure guarantees allocating down the irqdomain
hierarchy, and the implementers of domain_ops->alloc() need not to call
irq_domain_alloc_irqs_parent() any longer, just do the things they have to.

> 
>> 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.

Yes, you are right. Thanks for pointing out.

> 
>> 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.
> 

Yes, I got it. And one more thing I concerned is that when hierarchy
irqdomains is enabled, shouldn't the ack_parent() be called by default
by the irqchip->irq_ack() of each domain to ensure all the domains in
the delivery path ack this interrupt?

Thanks,
	Abel.


WARNING: multiple messages have this Message-ID (diff)
From: Abel <wuyun.wu@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Yinghai Lu <yinghai@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Grant Likely <grant.likely@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tony Luck <tony.luck@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains
Date: Tue, 30 Sep 2014 18:56:30 +0800	[thread overview]
Message-ID: <542A8C5E.3040901@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1409291707410.22082@ionos.tec.linutronix.de>

Hi Thomas,
On 2014/9/29 23:53, Thomas Gleixner wrote:

> On Mon, 29 Sep 2014, Abel wrote:
>> 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.

Yes, I know that. :)
What I meant is... (please see below)

> 
>> 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.

Actually the core infrastructure just calls domain->ops->alloc() which is
the one who really guarantees it by calling irq_domain_alloc_irqs_parent().
I think it's enough for a particular domain to pick a hwirq from itself for
that linux irq, and need not to care about its parent.
What I suggest is something like:

for (iter = domain; iter; iter = iter->parent) {
	ret = iter->ops->alloc(iter, virq, nr_irqs, arg);
	if (ret < 0) {
		mutex_unlock(&irq_domain_mutex);
		goto out_free_irq_data;
	}
}

in this way, the core infrastructure guarantees allocating down the irqdomain
hierarchy, and the implementers of domain_ops->alloc() need not to call
irq_domain_alloc_irqs_parent() any longer, just do the things they have to.

> 
>> 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.

Yes, you are right. Thanks for pointing out.

> 
>> 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.
> 

Yes, I got it. And one more thing I concerned is that when hierarchy
irqdomains is enabled, shouldn't the ack_parent() be called by default
by the irqchip->irq_ack() of each domain to ensure all the domains in
the delivery path ack this interrupt?

Thanks,
	Abel.


WARNING: multiple messages have this Message-ID (diff)
From: wuyun.wu@huawei.com (Abel)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains
Date: Tue, 30 Sep 2014 18:56:30 +0800	[thread overview]
Message-ID: <542A8C5E.3040901@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1409291707410.22082@ionos.tec.linutronix.de>

Hi Thomas,
On 2014/9/29 23:53, Thomas Gleixner wrote:

> On Mon, 29 Sep 2014, Abel wrote:
>> 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.

Yes, I know that. :)
What I meant is... (please see below)

> 
>> 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.

Actually the core infrastructure just calls domain->ops->alloc() which is
the one who really guarantees it by calling irq_domain_alloc_irqs_parent().
I think it's enough for a particular domain to pick a hwirq from itself for
that linux irq, and need not to care about its parent.
What I suggest is something like:

for (iter = domain; iter; iter = iter->parent) {
	ret = iter->ops->alloc(iter, virq, nr_irqs, arg);
	if (ret < 0) {
		mutex_unlock(&irq_domain_mutex);
		goto out_free_irq_data;
	}
}

in this way, the core infrastructure guarantees allocating down the irqdomain
hierarchy, and the implementers of domain_ops->alloc() need not to call
irq_domain_alloc_irqs_parent() any longer, just do the things they have to.

> 
>> 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.

Yes, you are right. Thanks for pointing out.

> 
>> 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.
> 

Yes, I got it. And one more thing I concerned is that when hierarchy
irqdomains is enabled, shouldn't the ack_parent() be called by default
by the irqchip->irq_ack() of each domain to ensure all the domains in
the delivery path ack this interrupt?

Thanks,
	Abel.

  reply	other threads:[~2014-09-30 10:58 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26 14:02 [RFT Part2 v2 00/24] Enable hierarchy irqdomian on x86 platforms Jiang Liu
2014-09-26 14:02 ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-29 12:22   ` Abel
2014-09-29 12:22     ` Abel
2014-09-29 12:22     ` Abel
2014-09-29 15:53     ` Thomas Gleixner
2014-09-29 15:53       ` Thomas Gleixner
2014-09-30 10:56       ` Abel [this message]
2014-09-30 10:56         ` Abel
2014-09-30 10:56         ` Abel
2014-09-30 21:49         ` Thomas Gleixner
2014-09-30 21:49           ` Thomas Gleixner
2014-10-07  1:50         ` Jiang Liu
2014-10-07  1:50           ` Jiang Liu
2014-10-07  1:26     ` Jiang Liu
2014-10-07  1:26       ` Jiang Liu
2014-10-01 14:23   ` Joe.C
2014-10-01 14:23     ` Joe.C
2014-10-22  7:24   ` Jiang Liu
2014-10-22  7:24     ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 02/24] genirq: Introduce helper functions to support stacked irq_chip Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 03/24] x86, irq: Save destination CPU ID in irq_cfg Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 04/24] x86, irq: Use hierarchy irqdomain to manage CPU interrupt vectors Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 05/24] x86, hpet: Use new irqdomain interfaces to allocate/free IRQ Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 06/24] x86, MSI: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 07/24] x86, uv: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 08/24] x86, htirq: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 09/24] x86, dmar: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 10/24] x86: irq_remapping: Introduce new interfaces to support hierarchy irqdomain Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 11/24] iommu/vt-d: Change prototypes to prepare for enabling " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 12/24] iommu/vt-d: Enhance Intel IR driver to suppport " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 13/24] iommu/amd: Enhance AMD " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 14/24] x86, hpet: Enhance HPET IRQ to support " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 16/24] x86, irq: Directly call native_compose_msi_msg() for DMAR IRQ Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 17/24] iommu/vt-d: Clean up unused MSI related code Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 18/24] iommu/amd: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 19/24] x86: irq_remapping: " Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 20/24] x86, irq: Clean up unused MSI related code and interfaces Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 21/24] iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 22/24] x86, irq: Use hierarchy irqdomain to manage DMAR interrupts Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 23/24] x86, htirq: Use hierarchy irqdomain to manage Hypertransport interrupts Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:02 ` [RFT v2 24/24] x86, uv: Use hierarchy irqdomain to manage UV interrupts Jiang Liu
2014-09-26 14:02   ` Jiang Liu
2014-09-26 14:29 ` [RFT Part2 v2 00/24] Enable hierarchy irqdomian on x86 platforms Borislav Petkov
2014-09-26 14:29   ` Borislav Petkov
2014-09-26 16:30   ` Aravind Gopalakrishnan
2014-09-26 16:30     ` Aravind Gopalakrishnan
2014-09-26 16:30     ` Aravind Gopalakrishnan
2014-09-28 11:05     ` Borislav Petkov
2014-09-28 11:05       ` Borislav Petkov
2014-09-28 11:15       ` Jiang Liu
2014-09-28 11:15         ` Jiang Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542A8C5E.3040901@huawei.com \
    --to=wuyun.wu@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mingo@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.