Re: [PATCH 0/2] Let pci_fixup_final access iommu_fwnode

2020-05-26 Thread Zhangfei Gao
On 2020/5/25 下午9:43, Joerg Roedel wrote: On Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote: Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. So calling pci_fixup_final after iommu_fwnode is

Re: [PATCH 1/2] PCI: Introduce PCI_FIXUP_IOMMU

2020-05-26 Thread Christoph Hellwig
On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote: > Some platform devices appear as PCI but are actually on the AMBA bus, > and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. > Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode > is allocated, instead

Re: [PATCH 1/2] PCI: Introduce PCI_FIXUP_IOMMU

2020-05-26 Thread Zhangfei Gao
Hi, Christoph On 2020/5/26 下午10:46, Christoph Hellwig wrote: On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote: Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. Here introducing PCI_FIXUP_IOMMU,

Re: [PATCH] iommu/dma: limit iova free size to unmmaped iova

2020-05-26 Thread guptap
On 2020-05-22 14:54, Robin Murphy wrote: On 2020-05-22 07:25, gup...@codeaurora.org wrote: On 2020-05-22 01:46, Robin Murphy wrote: On 2020-05-21 12:30, Prakash Gupta wrote: I agree, we shouldn't be freeing the partial iova. Instead just making sure if unmap was successful should be

Re: [PATCH v5 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-26 Thread Marek Szyprowski
Hi On 13.05.2020 15:47, Christoph Hellwig wrote: > I've pushed out a branch with the first three patches here: > > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper > > Gitweb: > > >

Re: [PATCH 2/2] iommu/sun50i: Constify sun50i_iommu_ops

2020-05-26 Thread Maxime Ripard
On Mon, May 25, 2020 at 11:49:58PM +0200, Rikard Falkeborn wrote: > The struct sun50i_iommu_ops is not modified and can be made const to > allow the compiler to put it in read-only memory. > > Before: >textdata bss dec hex filename > 143582501 64 16923421b

Re: [PATCH 1/2] iommu/hyper-v: Constify hyperv_ir_domain_ops

2020-05-26 Thread Wei Liu
On Mon, May 25, 2020 at 11:49:57PM +0200, Rikard Falkeborn wrote: > The struct hyperv_ir_domain_ops is not modified and can be made const to > allow the compiler to put it in read-only memory. > > Before: >textdata bss dec hex filename >29161180112052161460

Re: [PATCH] iommu: Relax ACS requirement for Intel RCiEP devices.

2020-05-26 Thread Alex Williamson
On Tue, 26 May 2020 15:17:35 -0700 Ashok Raj wrote: > All Intel platforms guarantee that all root complex implementations > must send transactions up to IOMMU for address translations. Hence for > RCiEP devices that are Vendor ID Intel, can claim exception for lack of > ACS support. > > > 3.16

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-26 Thread Jim Quinlan via iommu
Hello Andy, On Tue, May 26, 2020 at 4:54 PM Andy Shevchenko wrote: > > On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote: > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is > >

AMD IOMMU perf counters on Zen2

2020-05-26 Thread Alexander Monakov
Hello, I'd like to use IOMMU perf counters on a Zen 2 CPU (Ryzen 4500U, Renoir SoC). Unfortunately, init_iommu_perf_ctr fails because val2 != val, i.e. the counter appears not writable. However, if I patch the kernel to skip this check, the counters seem to increment when configured with perf

[PATCH] iommu: Relax ACS requirement for Intel RCiEP devices.

2020-05-26 Thread Ashok Raj
All Intel platforms guarantee that all root complex implementations must send transactions up to IOMMU for address translations. Hence for RCiEP devices that are Vendor ID Intel, can claim exception for lack of ACS support. 3.16 Root-Complex Peer to Peer Considerations When DMA remapping is

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-26 Thread Raj, Ashok
On Tue, May 26, 2020 at 12:26:54PM -0600, Alex Williamson wrote: > > > > > > I don't think the language in the spec is anything sufficient to handle > > > RCiEP uniquely. We've previously rejected kernel command line opt-outs > > > for ACS, and the extent to which those patches still float

[PATCH 4.14 10/59] iommu/amd: Fix over-read of ACPI UID from IVRS table

2020-05-26 Thread Greg Kroah-Hartman
From: Alexander Monakov [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-26 Thread Andy Shevchenko
On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote: > The new field in struct device 'dma_pfn_offset_map' is used to facilitate > the use of multiple pfn offsets between cpu addrs and dma addrs. It is > similar to 'dma_pfn_offset' except that the offset chosen depends on the > cpu or dma

[PATCH 5.4 012/111] iommu/amd: Fix over-read of ACPI UID from IVRS table

2020-05-26 Thread Greg Kroah-Hartman
From: Alexander Monakov [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is

[PATCH 4.9 09/64] iommu/amd: Fix over-read of ACPI UID from IVRS table

2020-05-26 Thread Greg Kroah-Hartman
From: Alexander Monakov [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is

[PATCH 4.19 12/81] iommu/amd: Fix over-read of ACPI UID from IVRS table

2020-05-26 Thread Greg Kroah-Hartman
From: Alexander Monakov [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is

[PATCH 5.6 014/126] iommu/amd: Fix over-read of ACPI UID from IVRS table

2020-05-26 Thread Greg Kroah-Hartman
From: Alexander Monakov [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

2020-05-26 Thread John Stultz
On Thu, May 14, 2020 at 12:34 PM wrote: > > On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote: > > Rob, Will, we're reaching the point where upstream has enough > functionality that this is becoming a critical issue for us. > > E.g. Lenovo Yoga C630 is lacking this and a single dts patch to

[PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-26 Thread Jim Quinlan via iommu
The new field in struct device 'dma_pfn_offset_map' is used to facilitate the use of multiple pfn offsets between cpu addrs and dma addrs. It is similar to 'dma_pfn_offset' except that the offset chosen depends on the cpu or dma address involved. Signed-off-by: Jim Quinlan ---

[PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips

2020-05-26 Thread Jim Quinlan via iommu
v2: Commit: "device core: Add ability to handle multiple dma offsets" o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph) o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph) o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP o

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-26 Thread Raj, Ashok
Hi Alex, I was able to find better language in the IOMMU spec that gaurantees the behavior we need. See below. On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote: > On Tue, 5 May 2020 07:56:06 -0700 > "Raj, Ashok" wrote: > > > On Tue, May 05, 2020 at 08:05:14AM -0600, Alex

[PATCH v3] dma: Fix max PFN arithmetic overflow on 32 bit systems

2020-05-26 Thread Alexander Dahl
The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is 4 294 967 296 or 0x1 which is no problem on 64 bit systems. The patch does not change the later overall result of 0x10 for MAX_DMA32_PFN. The new calculation yields the same result, but does not require 64 bit

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-26 Thread Alex Williamson
On Tue, 26 May 2020 11:06:48 -0700 "Raj, Ashok" wrote: > Hi Alex, > > I was able to find better language in the IOMMU spec that gaurantees > the behavior we need. See below. > > > On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote: > > On Tue, 5 May 2020 07:56:06 -0700 > > "Raj,

Re: [PATCH] iommu: Relax ACS requirement for Intel RCiEP devices.

2020-05-26 Thread Kuppuswamy, Sathyanarayanan
On 5/26/20 3:17 PM, Ashok Raj wrote: All Intel platforms guarantee that all root complex implementations must send transactions up to IOMMU for address translations. Hence for RCiEP devices that are Vendor ID Intel, can claim exception for lack of ACS support. 3.16 Root-Complex Peer to Peer

Re: [PATCH v7 18/24] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

2020-05-26 Thread Xiang Zheng
Hi Jean, This patch only enables HTTU bits in CDs. Is it also neccessary to enable HTTU bits in STEs in this patch? On 2020/5/20 1:54, Jean-Philippe Brucker wrote: > If the SMMU supports it and the kernel was built with HTTU support, > enable hardware update of access and dirty flags. This is

RE: [RFC] Use SMMU HTTU for DMA dirty page tracking

2020-05-26 Thread Tian, Kevin
> From: Xiang Zheng > Sent: Monday, May 25, 2020 7:34 PM > > [+cc Kirti, Yan, Alex] > > On 2020/5/23 1:14, Jean-Philippe Brucker wrote: > > Hi, > > > > On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote: > >> Hi all, > >> > >> Is there any plan for enabling SMMU HTTU? > > > > Not

Re: [PATCH v5 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-26 Thread Daniel Vetter
On Tue, May 26, 2020 at 9:01 AM Marek Szyprowski wrote: > > Hi > > On 13.05.2020 15:47, Christoph Hellwig wrote: > > I've pushed out a branch with the first three patches here: > > > > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper > > > > Gitweb: > > > > > >

[PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-26 Thread Zhangfei Gao
Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow down iommu probing as

[PATCH 1/2] PCI: Introduce PCI_FIXUP_IOMMU

2020-05-26 Thread Zhangfei Gao
Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow down iommu probing as

[PATCH 2/2] iommu: calling pci_fixup_iommu in iommu_fwspec_init

2020-05-26 Thread Zhangfei Gao
Calling pci_fixup_iommu in iommu_fwspec_init, which alloc iommu_fwnode. Some platform devices appear as PCI but are actually on the AMBA bus, and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. So calling pci_fixup_iommu after iommu_fwnode is allocated. Signed-off-by: Zhangfei Gao