linux-kernel - Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

Open Source and information security mailing list archives

Message-ID: <56FBF2B7.8090601@linaro.org>
Date:	Wed, 30 Mar 2016 17:37:27 +0200
From:	Eric Auger <eric.auger@...aro.org>
To:	Will Deacon <will.deacon@....com>, Arnd Bergmann <arnd@...db.de>
Cc:	Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
	arm@...nel.org, pawel.moll@....com, ijc+devicetree@...lion.org.uk,
	linux-kernel@...r.kernel.org, robh+dt@...nel.org,
	leo.duran@....com,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
	galak@...eaurora.org, thomas.lendacky@....com,
	Robin Murphy <robin.murphy@....com>,
	linux-arm-kernel@...ts.infradead.org, brijeshkumar.singh@....com,
	Christoffer Dall <christoffer.dall@...aro.org>,
	"eric.auger@...com" <eric.auger@...com>
Subject: Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

Dear all,
On 01/28/2016 03:27 PM, Will Deacon wrote:
> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>
>>>> Will, Robin, thoughts?
>>>
>>> Any IDs specified here would only apply to DMA by the "platform device" 
>>> side of the host controller itself (as would an equivalent "iommus" 
>>> property on pcie0 once I finish the SMMUv2 generic binding support I'm 
>>> working on). In terms of PCI devices, the "mmu-masters" property is 
>>> overloaded such that only its existence matters, to identify that there 
>>> _is_ a relationship between the SMMU and the PCI bus(es) behind that 
>>> host controller.
>>
>> I wasn't aware that this was actually still specified. I had hoped
>> we were getting rid of mmu-masters before anyone actually started
>> using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.
>>
>> Does anyone know what happened to the plan to use the iommu DT binding
>> for the ARM SMMU instead? Do we now have to support both ways indefinitely?
> 
> We always did -- Seattle used the mmu-masters binding before the generic
> binding even existed. Robin has been working on patches to get of_xlate
> up and running, but it got held up by Laurent's series which didn't end
> up going anywhere.
> 
> Will
Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

I observe the fault only when I override the PCIe ACS property in my
case which was pretty confusing (each PF/VF is put in a separate group).

What is the correct syntax then: mmu-masters = <&pcie0>?

instead of

+			 mmu-masters = <&pcie0
+				/* 1:00:[0,3] */ 256 257 258 259
+				/* 2:00:[0,3] */ 512 513 514 515
+				/* 3:00:[0,3] */ 768 769 770 771
+				/* 4:00:[0,3] */ 1024 1025 1026 1027>

Is there a plan to update/upstream the dt description for PCIe smmu.

Thank you in advance

Best Regards

Eric

> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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