[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4118142.2mQ5BlBdTZ@wuerfel>
Date: Tue, 04 Feb 2014 20:21:38 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
linux-pci <linux-pci@...r.kernel.org>,
Liviu Dudau <Liviu.Dudau@....com>,
LKML <linux-kernel@...r.kernel.org>,
Catalin Marinas <Catalin.Marinas@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
LAKML <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: Add architecture support for PCI
On Tuesday 04 February 2014 12:10:55 Jason Gunthorpe wrote:
>
> For instance to support peer-to-peer IO you need to have a consisent,
> non-overlapping set of bus/device/function/tag to uniquely route TLPs
> within the chip. Cross domain TLP routing in HW is non-trivial.
Yes, that is a good reason.
> IOMMUs (and SR-IOv) rely on the BDF to identify the originating device
> for each TLP. Multiple domains means a much more complex IOMMU
> environment.
I fear we already have to support complex IOMMU setups on ARM,
whether there are multiple PCI domains or not. But it would be
nice in theory not to require it.
> Failure to integrate on-chip devices into the PCI world also means
> thing like SR-IOv won't work sanely with on-chip devices.
I'd consider this a feature ;)
But you are probably right: people will do SR-IOV whether we like
it or not, and they will try to do it on non-PCI devices too,
and great suffering will be involved.
Arnd
--
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/
Powered by blists - more mailing lists