From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Yijing Wang <wangyijing@huawei.com>
Cc: 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 10:29:31 +0000 [thread overview]
Message-ID: <546F140B.1050607@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411210233250.6439@nanos>
Hi Thomas,
On 21/11/14 01:46, Thomas Gleixner wrote:
> On Fri, 21 Nov 2014, Yijing Wang wrote:
>> On 2014/11/21 0:31, Marc Zyngier wrote:
>>> Bjorn, Yijing,
>>>
>>> I've just realized that patch c167caf8d174 (PCI/MSI: Remove useless
>>> bus->msi assignment) completely breaks MSI on arm64 when using the new
>>> MSI stacked domain:
>>
>> Sorry, this is my first part to refactor MSI related code, now how
>> to get pci msi_controller depends arch
>> functions(pcibios_msi_controller() or arch_setup_msi_irq()), we are
>> working on generic pci_host_bridge, after that, we could eventually
>> eliminate MSI arch functions and find pci dev 's msi controller by
>> pci_host_bridge->get_msi_controller().
>
> The main question is why you think that pci_host_bridge is the proper
> place to store that information.
>
> On x86 we have DMAR units associated to a single device. Each DMAR
> unit is a seperate MSI irq domain.
>
> Can you guarantee that the pci_host_bridge is the right point to
> provide the association of the device to the irq domain?
>
> 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. What I don't
completely see is how the host bridge has all required the knowledge.
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).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2014-11-21 10:29 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 [this message]
2014-11-21 10:49 ` Thomas Gleixner
2014-11-21 11:30 ` Marc Zyngier
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=546F140B.1050607@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).