linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Yijing Wang <wangyijing@huawei.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Arjan van de Ven <arjan@infradead.org>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: Removal of bus->msi assignment breaks MSI with stacked domains
Date: Fri, 21 Nov 2014 11:30:22 +0000	[thread overview]
Message-ID: <546F224E.2080106@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411211142051.6439@nanos>

On 21/11/14 10:49, Thomas Gleixner wrote:
> Marc,
> 
> On Fri, 21 Nov 2014, Marc Zyngier wrote:
>> On 21/11/14 01:46, Thomas Gleixner wrote:
>>> So the real question is:
>>>
>>>    What is the association level requirement to properly identify the
>>>    irqdomain for a specific device on any given architecture with and
>>>    without IOMMU, interrupt redirection etc.
>>>
>>> To be honest: I don't know.
>>>
>>> My gut feeling tells me that it's at the device level, but I really
>>> leave that decision to the experts in that field.
>>
>> Given the above requirement (single device associated to DMAR), I can
>> see two possibilities:
>> - we represent DMAR as a single PCI bus: feels a bit artificial
>> - we move the MSI domain to the device, as you suggested.
>>
>> The second one seems a lot more attractive to me.
> 
> And that's very useful if you want to support MSI on non PCI
> devices.
> 
>> Also, it is not clear to me what is the advantage of getting rid of the
>> MSI controller. By doing so, we loose an important part of the topology
>> information (the irq domain is another level of abstraction).
> 
> That was probably my misunderstanding of the msi controller. I had the
> impression it's just there to expose the MSI properties of a device,
> i.e. a magic wrapper which can be replaced by the MSI irqdomain work.
> 
> If that handles other information as well, then it's probably a
> misnomer to begin with.

At the moment, it serves multiple purpose:
- MSI configuration via setup_irq/teardown_irq: this is what most 32bit
ARM system are using (it has been introduced last year for that very
purpose)
- PCI controller vs MSI hw matching: both arm and arm64 are using this
to associate the PCI controller with the matching MSI hw, using the
device tree (msi-controller and msi-parent properties in DT, of_node
field in the msi_controller structure).
- associated irq_domain (I've added that bit).

I expect setup_irq and co to disappear at some point, once all the users
have been converted to stacked domains. The matching information is
harder to let go though. But that could be a structure that doesn't have
to be inflicted on everyone, if we can go from:

pci-device -> msi-controller -> irq-domain

to

pci-device -> irq-domain -> dt-topology-information

Thoughts?

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2014-11-21 11:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 16:31 Removal of bus->msi assignment breaks MSI with stacked domains Marc Zyngier
2014-11-20 21:53 ` Bjorn Helgaas
2014-11-20 23:10   ` Thomas Gleixner
2014-11-20 23:30     ` Bjorn Helgaas
2014-11-21  9:33       ` Marc Zyngier
2014-11-21  1:54     ` Yijing Wang
2014-11-21  2:25       ` Jiang Liu
2014-11-21  3:46         ` Yijing Wang
2014-11-21 10:00       ` Marc Zyngier
2014-11-21 17:31       ` Bjorn Helgaas
2014-11-22  4:13         ` Yijing Wang
2014-11-21  1:22 ` Yijing Wang
2014-11-21  1:46   ` Thomas Gleixner
2014-11-21  2:03     ` Jiang Liu
2014-11-21  2:12       ` Yijing Wang
2014-11-21  2:05     ` Yijing Wang
2014-11-21  8:46       ` Lucas Stach
2014-11-21 10:29     ` Marc Zyngier
2014-11-21 10:49       ` Thomas Gleixner
2014-11-21 11:30         ` Marc Zyngier [this message]
2014-11-21 12:04       ` Yijing Wang
2014-11-21 10:11   ` Marc Zyngier
2014-11-21 11:57     ` Yijing Wang

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=546F224E.2080106@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arjan@infradead.org \
    --cc=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wangyijing@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).