[PATCH v3 1/1] iommu: Add config option to set lazy mode as default

2019-03-28 Thread Zhen Lei
This allows the default behaviour to be controlled by a kernel config option instead of changing the command line for the kernel to include "iommu.strict=0" on ARM64 where this is desired. This is similar to CONFIG_IOMMU_DEFAULT_PASSTHROUGH. Signed-off-by: Zhen Lei --- arch/s390/pci/pci_dma.c

Re: [PATCH v2 00/10] iommu/vt-d: Bounce buffer for untrusted devices

2019-03-28 Thread Lu Baolu
Hi, On 3/29/19 12:11 AM, Christoph Hellwig wrote: On Thu, Mar 28, 2019 at 02:33:04PM +0800, Lu Baolu wrote: For the swiotlb APIs, I am thinking about keeping current APIs untouched and adding below new ones for bounce page. In the lon run I'd like tow avoid duplicate APIs, especially as the

[PATCH] x86/calgary: fix bitcast type warnings

2019-03-28 Thread Jann Horn via iommu
The sparse checker attempts to ensure that all conversions between fixed-endianness numbers and numbers with native endianness are explicit. However, the calgary code reads and writes big-endian numbers from/to IO memory using {read,write}{l,q}(), which return native-endian numbers. This could be

Re: [PATCH v2 3/7] iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions

2019-03-28 Thread James Sewart via iommu
Hey Lu, > On 26 Mar 2019, at 01:24, Lu Baolu wrote: > > Hi James, > > On 3/25/19 8:57 PM, James Sewart wrote: Theres an issue that if we choose to alloc a new resv_region with type IOMMU_RESV_DIRECT, we will need to refactor intel_iommu_put_resv_regions to free this entry type

[PATCH v1 1/3] PCI: qcom: Setup PCIE20_PARF_BDF_TRANSLATE_N

2019-03-28 Thread Marc Gonzalez
Initialize PCIE20_PARF_BDF_TRANSLATE_N for ops_2_3_2. Signed-off-by: Marc Gonzalez --- drivers/pci/controller/dwc/pcie-qcom.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 0ed235d560e3..5e5522a427b8

[PATCH v1 3/3] arm64: dts: qcom: msm8998: Add PCIe PHY and RC nodes

2019-03-28 Thread Marc Gonzalez
Add MSM8998 PCIe QMP PHY and PCIe root complex DT nodes. Signed-off-by: Marc Gonzalez --- arch/arm64/boot/dts/qcom/msm8998.dtsi | 78 +++ 1 file changed, 78 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi index

[PATCH v1 2/3] arm64: dts: qcom: msm8998: Add PCIe SMMU node

2019-03-28 Thread Marc Gonzalez
ANOC1 SMMU filters PCIe accesses. Signed-off-by: Marc Gonzalez --- arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi index f9a922fdae75..5a1c0961b281 100644

[PATCH v1 0/3] PCIe and AR8151 on APQ8098/MSM8998

2019-03-28 Thread Marc Gonzalez
Hello everyone, After a lot of poking, I am finally able to use the AR8151 ethernet on the APQ8098 board. The magic bits are the iommu-map prop and the PCIE20_PARF_BDF_TRANSLATE_N setup. The WIP thread is archived here: https://marc.info/?t=15505953924=1=2 Marc Gonzalez (3): PCI: qcom:

Re: [PATCH v2 00/10] iommu/vt-d: Bounce buffer for untrusted devices

2019-03-28 Thread Christoph Hellwig
On Thu, Mar 28, 2019 at 02:33:04PM +0800, Lu Baolu wrote: > For the swiotlb APIs, I am thinking about keeping current APIs untouched > and adding below new ones for bounce page. In the lon run I'd like tow avoid duplicate APIs, especially as the current low-level swiotlb APIs only two callers.

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

2019-03-28 Thread Robin Murphy
On 28/03/2019 10:34, Srinath Mannam wrote: Hi Robin, Thanks for your feedback. Please see my reply in line. On Wed, Mar 27, 2019 at 8:32 PM Robin Murphy wrote: On 25/01/2019 10:13, Srinath Mannam wrote: Few SOCs have limitation that their PCIe host can't allow few inbound address ranges.

Re: [PATCH] iommu/amd: Reserve exclusion range in iova-domain

2019-03-28 Thread Gary R Hook
On 3/28/19 5:44 AM, Joerg Roedel wrote: > From: Joerg Roedel > > If a device has an exclusion range specified in the IVRS > table, this region needs to be reserved in the iova-domain > of that device. This hasn't happened until now and can cause > data corruption on data transfered with these

[PATCH] iommu/amd: Reserve exclusion range in iova-domain

2019-03-28 Thread Joerg Roedel
From: Joerg Roedel If a device has an exclusion range specified in the IVRS table, this region needs to be reserved in the iova-domain of that device. This hasn't happened until now and can cause data corruption on data transfered with these devices. Treat exclusion ranges as reserved regions

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

2019-03-28 Thread Srinath Mannam via iommu
Hi Robin, Thanks for your feedback. Please see my reply in line. On Wed, Mar 27, 2019 at 8:32 PM Robin Murphy wrote: > > On 25/01/2019 10:13, Srinath Mannam wrote: > > Few SOCs have limitation that their PCIe host can't allow few inbound > > address ranges. Allowed inbound address ranges are

[PATCH] driver core: Postpone DMA tear-down until after devres release for probe failure

2019-03-28 Thread John Garry
In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after devres release"), we changed the ordering of tearing down the device DMA ops and releasing all the device's resources; this was because the DMA ops should be maintained until we release the device's managed DMA memories.

Re: [PATCH v2 00/10] iommu/vt-d: Bounce buffer for untrusted devices

2019-03-28 Thread Lu Baolu
Hi, On 3/27/19 2:48 PM, Christoph Hellwig wrote: On Wed, Mar 27, 2019 at 02:34:56PM +0800, Lu Baolu wrote: - During the v1 review cycle, we discussed the possibility of reusing swiotlb code to avoid code dumplication, but we found the swiotlb implementations are not ready for the

Re: [PATCH v2 1/1] iommu: Add config option to set lazy mode as default

2019-03-28 Thread Leizhen (ThunderTown)
On 2019/3/28 3:18, Robin Murphy wrote: > On 27/03/2019 15:00, Zhen Lei wrote: >> This allows the default behaviour to be controlled by a kernel config >> option instead of changing the command line for the kernel to include >> "iommu.strict=0" on ARM64 where this is desired. >> >> This is