Re: [Issue]platform/x86: iommu: System can't shutdown because iommu driver keeps checking the status of DMA_GSTS_TES

2020-06-30 Thread Koba Ko
On Mon, Jun 15, 2020 at 3:20 PM Lu Baolu wrote: > > Hi Koba Ko, > > On 2020/6/15 11:19, Koba Ko wrote: > > hi All, > > I have a machine and there's only intel gpu. > > the secureboot and vt-d is enabled in BIOS. > > On the Ubuntu desktop, I do s2idle first and restart the machine. > > The machine

RE: [PATCH 4/4] iommu/vt-d: Add page response ops support

2020-06-30 Thread Tian, Kevin
> From: Lu Baolu > Sent: Sunday, June 28, 2020 8:34 AM > > After a page request is handled, software must response the device which > raised the page request with the handling result. This is done through > the iommu ops.page_response if the request was reported to outside of > vendor iommu

RE: [PATCH 3/4] iommu/vt-d: Report page request faults for guest SVA

2020-06-30 Thread Tian, Kevin
> From: Lu Baolu > Sent: Sunday, June 28, 2020 8:34 AM > > A pasid might be bound to a page table from a VM guest via the iommu > ops.sva_bind_gpasid. In this case, when a DMA page fault is detected > on the physical IOMMU, we need to inject the page fault request into > the guest. After the

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 01:10, Krishna Reddy wrote: > NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave > IOVA accesses across them. > Add NVIDIA implementation for dual ARM MMU-500s and add new compatible > string for Tegra194 SoC SMMU topology. There is no description here of the 3rd

Re: [PATCH 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory

2020-06-30 Thread Joerg Roedel
Hi Jerry, On Fri, Jun 12, 2020 at 04:10:59PM -0700, Jerry Snitselaar wrote: > Move Intel Kconfig and Makefile bits down into intel directory > with the rest of the Intel specific files. > > Cc: Joerg Roedel > Cc: Lu Baolu > Signed-off-by: Jerry Snitselaar > --- > drivers/iommu/Kconfig

Re: [PATCH v2 0/2] iommu/amd: Don't use atomic64_t for domain->pt_root

2020-06-30 Thread Joerg Roedel
On Fri, Jun 26, 2020 at 08:30:21AM -0400, Qian Cai wrote: > BTW, from the previous discussion, Linus mentioned, > > “ > The thing is, the 64-bit atomic reads/writes are very expensive on > 32-bit x86. If it was just a native pointer, it would be much cheaper > than an "atomic64_t". > “ > >

Re: [PATCH] iommu: SUN50I_IOMMU should depend on HAS_DMA

2020-06-30 Thread Joerg Roedel
On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote: > On 2020-06-29 13:11, Geert Uytterhoeven wrote: > > If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config): > > > > drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap': > > dma-iommu.c:(.text+0x92e): undefined reference to

Re: [PATCH v7 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 29/06/2020 23:49, Krishna Reddy wrote: >>> + if (!nvidia_smmu->bases[0]) >>> + nvidia_smmu->bases[0] = smmu->base; >>> + >>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); } > >> Not critical -- just a nit: why not put the bases[0] in init()? > > smmu->base

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Heikki Krogerus
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > Add a new (optional) field to denote the physical location of a device > in the system, and expose it in sysfs. This was discussed here: > https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/ > > (The primary choice

Re: [PATCH] iommu: SUN50I_IOMMU should depend on HAS_DMA

2020-06-30 Thread Robin Murphy
On 2020-06-30 11:09, Joerg Roedel wrote: On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote: On 2020-06-29 13:11, Geert Uytterhoeven wrote: If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config): drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap': dma-iommu.c:(.text+0x92e):

Re: [PATCH v5 09/10] iommu/mediatek: Modify MMU_CTRL register setting

2020-06-30 Thread chao hao
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote: > > On 29/06/2020 09:13, Chao Hao wrote: > > MT8173 is different from other SoCs for MMU_CTRL register. > > For mt8173, its bit9 is in_order_write_en and doesn't use its > > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en

Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure

2020-06-30 Thread chao hao
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote: > Hi Chao, > > This is also ok for me. Only two format nitpick. > > On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote: > > Given the fact that we are adding more and more plat_data bool values, > > it would make sense to use a u32 flags register

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Greg Kroah-Hartman
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > Add a new (optional) field to denote the physical location of a device > in the system, and expose it in sysfs. This was discussed here: > https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/ > > (The primary choice

Re: [PATCH v2 4/7] PCI: Add device even if driver attach failed

2020-06-30 Thread Greg Kroah-Hartman
On Mon, Jun 29, 2020 at 09:49:40PM -0700, Rajat Jain wrote: > device_attach() returning failure indicates a driver error while trying to > probe the device. In such a scenario, the PCI device should still be added > in the system and be visible to the user. > > This patch partially reverts: >

[PATCH] scatterlist: protect parameters of the sg_table related macros

2020-06-30 Thread Marek Szyprowski
Add brackets to protect parameters of the recently added sg_table related macros from side-effects. Fixes: 709d6d73c756 ("scatterlist: add generic wrappers for iterating over sgtable objects") Signed-off-by: Marek Szyprowski --- include/linux/scatterlist.h | 8 1 file changed, 4

[PATCH] iommu: move sg_table wrapper out of CONFIG_IOMMU_SUPPORT

2020-06-30 Thread Marek Szyprowski
Move the recently added sg_table wrapper out of CONFIG_IOMMU_SUPPORT to let the client code copile also when IOMMU support is disabled. Fixes: 48530d9fab0d ("iommu: add generic helper for mapping sgtable objects") Signed-off-by: Marek Szyprowski --- include/linux/iommu.h | 32

Re: [PATCH 1/2] iommu/sun50i: Change the readl timeout to the atomic variant

2020-06-30 Thread Joerg Roedel
On Sun, Jun 28, 2020 at 08:08:43PM +0200, Maxime Ripard wrote: > The flush_all_tlb call back can be called from an atomic context, so using > readl_poll_timeout that embeds a udelay doesn't work. > > Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver") > Signed-off-by: Maxime Ripard

Re: [PATCH v5 04/10] iommu/mediatek: Setting MISC_CTRL register

2020-06-30 Thread chao hao
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote: > > On 29/06/2020 09:13, Chao Hao wrote: > > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition > > in MISC_CTRL register. > > F_MMU_STANDARD_AXI_MODE_BIT: > > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not

Re: [Possible PATCH] iommu/qcom: Change CONFIG_BIG_ENDIAN to CONFIG_CPU_BIG_ENDIAN

2020-06-30 Thread Joerg Roedel
On Sat, Jun 06, 2020 at 12:16:17PM -0700, Joe Perches wrote: > CONFIG_BIG_ENDIAN does not exist as a Kconfig symbol. > > Signed-off-by: Joe Perches > --- > > I don't have the hardware, so I can't tell if this is a > correct change, but it is a logical one. > > Found by a test script that looks

Re: [PATCH v5 03/10] iommu/mediatek: Modify the usage of mtk_iommu_plat_data structure

2020-06-30 Thread Yong Wu
Hi Chao, This is also ok for me. Only two format nitpick. On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote: > Given the fact that we are adding more and more plat_data bool values, > it would make sense to use a u32 flags register and add the appropriate > macro definitions to set and check for

Re: [PATCH v2 6/7] PCI: Move pci_dev->untrusted logic to use device location instead

2020-06-30 Thread Lu Baolu
On 2020/6/30 12:49, Rajat Jain wrote: The firmware was provinding "ExternalFacing" attribute on PCI root ports, to allow the kernel to mark devices behind it as external. Note that the firmware provides an immutable, read-only property, i.e. the location of the device. The use of (external)

Re: [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

2020-06-30 Thread Jon Hunter
On 30/06/2020 01:10, Krishna Reddy wrote: > Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based > on ARM MMU-500. > > Signed-off-by: Krishna Reddy > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 + > 1 file changed, 5 insertions(+) > > diff --git

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

2020-06-30 Thread Marek Szyprowski
Hi All, On 19.06.2020 12:36, Marek Szyprowski wrote: > During the Exynos DRM GEM rework and fixing the issues in the. > drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most > drivers in DRM framework incorrectly use nents and orig_nents entries of > the struct sg_table. > > In

Re: [PATCH 3/3] iommu/amd: Actually enforce geometry aperture

2020-06-30 Thread Joerg Roedel
Hi Sebastian, On Fri, Jun 05, 2020 at 04:56:55PM +0200, Sebastian Ott wrote: > Add a check to enforce that I/O virtual addresses picked by iommu API > users stay within the domains geometry aperture. > > Signed-off-by: Sebastian Ott > --- > drivers/iommu/amd_iommu.c | 5 + > 1 file

Re: [PATCH] iommu: Allow page responses without PASID

2020-06-30 Thread Joerg Roedel
On Tue, Jun 16, 2020 at 04:47:14PM +0200, Jean-Philippe Brucker wrote: > Some PCIe devices do not expect a PASID value in PRI Page Responses. > If the "PRG Response PASID Required" bit in the PRI capability is zero, > then the OS should not set the PASID field. Similarly on Arm SMMU, > responses

Re: [PATCH v7 31/36] staging: tegra-vde: fix common struct sg_table related issues

2020-06-30 Thread Marek Szyprowski
On 21.06.2020 06:00, Dmitry Osipenko wrote: > В Fri, 19 Jun 2020 12:36:31 +0200 > Marek Szyprowski пишет: > >> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() >> function returns the number of the created entries in the DMA address >> space. However the subsequent calls to the >>

Re: [PATCH v2 01/12] ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for NC

2020-06-30 Thread Lorenzo Pieralisi
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote: [...] > > For devices that aren't described in the DSDT - IORT translations > > are determined by their ACPI parent device. Do you see/Have you > > found any issue with this approach ? > > The spec says "Describes the IO relationships

Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault

2020-06-30 Thread chao hao
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote: > On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote: > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below > > diagram). > > If the larb's number is over 8, we use a sub_common for merging > > several larbs into one larb. At

Re: [PATCH v2 2/7] PCI: Set "untrusted" flag for truly external devices only

2020-06-30 Thread Lu Baolu
On 2020/6/30 12:49, Rajat Jain wrote: The "ExternalFacing" devices (root ports) are still internal devices that sit on the internal system fabric and thus trusted. Currently they were being marked untrusted. This patch uses the platform flag to identify the external facing devices and then use

Re: [PATCH v2 2/7] PCI: Set "untrusted" flag for truly external devices only

2020-06-30 Thread Greg Kroah-Hartman
On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote: > The "ExternalFacing" devices (root ports) are still internal devices that > sit on the internal system fabric and thus trusted. Currently they were > being marked untrusted. > > This patch uses the platform flag to identify the

Re: [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks

2020-06-30 Thread Jon Hunter
On 30/06/2020 01:10, Krishna Reddy wrote: > Add global/context fault hooks to allow NVIDIA SMMU implementation > handle faults across multiple SMMUs. Nit ... this is not just for NVIDIA, but this allows anyone to add custom global/context and fault hooks. So I think that the changelog should be

Re: [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu

2020-06-30 Thread Joerg Roedel
On Thu, Jun 25, 2020 at 03:08:23PM +0200, Joerg Roedel wrote: > Joerg Roedel (13): > iommu/exynos: Use dev_iommu_priv_get/set() > iommu/vt-d: Use dev_iommu_priv_get/set() > iommu/msm: Use dev_iommu_priv_get/set() > iommu/omap: Use dev_iommu_priv_get/set() > iommu/rockchip: Use

Re: [PATCH] iommu: move sg_table wrapper out of CONFIG_IOMMU_SUPPORT

2020-06-30 Thread Joerg Roedel
On Tue, Jun 30, 2020 at 10:17:56AM +0200, Marek Szyprowski wrote: > Move the recently added sg_table wrapper out of CONFIG_IOMMU_SUPPORT to > let the client code copile also when IOMMU support is disabled. > > Fixes: 48530d9fab0d ("iommu: add generic helper for mapping sgtable objects") >

[PATCH v8] videobuf2: use sgtable-based scatterlist wrappers

2020-06-30 Thread Marek Szyprowski
Use recently introduced common wrappers operating directly on the struct sg_table objects and scatterlist page iterators to make the code a bit more compact, robust, easier to follow and copy/paste safe. No functional change, because the code already properly did all the scaterlist related calls.

Re: [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks

2020-06-30 Thread Robin Murphy
On 2020-06-30 09:37, Jon Hunter wrote: On 30/06/2020 01:10, Krishna Reddy wrote: Add global/context fault hooks to allow NVIDIA SMMU implementation handle faults across multiple SMMUs. Nit ... this is not just for NVIDIA, but this allows anyone to add custom global/context and fault hooks.

Re: [PATCH V4 1/3] iommu: Add support to change default domain of an iommu group

2020-06-30 Thread Joerg Roedel
On Thu, Jun 04, 2020 at 06:32:06PM -0700, Sai Praneeth Prakhya wrote: > +static int iommu_change_dev_def_domain(struct iommu_group *group, int type) > +{ > + struct iommu_domain *prev_dom; > + struct group_device *grp_dev; > + const struct iommu_ops *ops; > + int ret, dev_def_dom;

Re: [PATCH 0/2] iommu/renesas: Add support for r8a77961

2020-06-30 Thread Joerg Roedel
On Thu, Jun 11, 2020 at 08:10:28PM +0900, Yoshihiro Shimoda wrote: > This patch series is based on next-20200611. > > Yoshihiro Shimoda (2): > dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a77961 support > iommu/renesas: Add support for r8a77961 Applied, thanks.

Re: [PATCH] iommu/amd: Print extended features in one line to fix divergent log levels

2020-06-30 Thread Jörg Rödel
On Wed, Jun 17, 2020 at 12:04:20AM +0200, Paul Menzel wrote: > drivers/iommu/amd_iommu_init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 01:10, Krishna Reddy wrote: > NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave > IOVA accesses across them. > Add NVIDIA implementation for dual ARM MMU-500s and add new compatible > string for Tegra194 SoC SMMU topology. > > Signed-off-by: Krishna Reddy > --- >

Re: [PATCH] iommu: add include/uapi/linux/iommu.h to MAINTAINERS file

2020-06-30 Thread Joerg Roedel
On Fri, Jun 05, 2020 at 12:00:25AM -0700, Jerry Snitselaar wrote: > When include/uapi/linux/iommu.h was created it was never > added to the file list in MAINTAINERS. > > Cc: Joerg Roedel > Signed-off-by: Jerry Snitselaar > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Applied,

Re: [PATCH v5 07/10] iommu/mediatek: Add REG_MMU_WR_LEN register definition

2020-06-30 Thread chao hao
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote: > > On 29/06/2020 09:13, Chao Hao wrote: > > Some platforms(ex: mt6779) need to improve performance by setting > > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control > > whether we need to set the register. If the

Re: [PATCH v5 06/10] iommu/mediatek: Add sub_comm id in translation fault

2020-06-30 Thread Yong Wu
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote: > The max larb number that a iommu HW support is 8(larb0~larb7 in the below > diagram). > If the larb's number is over 8, we use a sub_common for merging > several larbs into one larb. At this case, we will extend larb_id: > bit[11:9] means

RE: [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

2020-06-30 Thread Pritesh Raithatha
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based on ARM > MMU-500. > > Signed-off-by: Krishna Reddy Reviewed-by: Pritesh Raithatha ___ iommu mailing list iommu@lists.linux-foundation.org

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Pritesh Raithatha
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave IOVA > accesses across them. > Add NVIDIA implementation for dual ARM MMU-500s and add new compatible > string for Tegra194 SoC SMMU topology. > > Signed-off-by: Krishna Reddy Reviewed-by: Pritesh Raithatha

RE: [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks

2020-06-30 Thread Pritesh Raithatha
> Add global/context fault hooks to allow NVIDIA SMMU implementation handle > faults across multiple SMMUs. > > Signed-off-by: Krishna Reddy Reviewed-by: Pritesh Raithatha ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [Issue]platform/x86: iommu: System can't shutdown because iommu driver keeps checking the status of DMA_GSTS_TES

2020-06-30 Thread Lu Baolu
Hi Koba, On 2020/6/30 15:31, Koba Ko wrote: On Mon, Jun 15, 2020 at 3:20 PM Lu Baolu wrote: Hi Koba Ko, On 2020/6/15 11:19, Koba Ko wrote: hi All, I have a machine and there's only intel gpu. the secureboot and vt-d is enabled in BIOS. On the Ubuntu desktop, I do s2idle first and restart

[PATCH v8] rapidio: fix common struct sg_table related issues

2020-06-30 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the

Re: [PATCH] iommu/iova: Don't BUG on invalid PFNs

2020-06-30 Thread Joerg Roedel
On Tue, Jun 02, 2020 at 02:08:18PM +0100, Robin Murphy wrote: > Unlike the other instances which represent a complete loss of > consistency within the rcache mechanism itself, or a fundamental > and obvious misconfiguration by an IOMMU driver, the BUG_ON() in > iova_magazine_free_pfns() can be

Re: [PATCH v7 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Robin Murphy
On 2020-06-30 11:23, Jon Hunter wrote: On 29/06/2020 23:49, Krishna Reddy wrote: + if (!nvidia_smmu->bases[0]) + nvidia_smmu->bases[0] = smmu->base; + + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); } Not critical -- just a nit: why not put the bases[0] in

Re: [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

2020-06-30 Thread Robin Murphy
On 2020-06-30 01:10, Krishna Reddy wrote: Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based on ARM MMU-500. Signed-off-by: Krishna Reddy --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH] iommu/amd: Make amd_iommu_apply_ivrs_quirks() static inline

2020-06-30 Thread Joerg Roedel
From: Joerg Roedel At least the version in the header file to fix a compile warning about the function being unused. Reported-by: Borislav Petkov Signed-off-by: Joerg Roedel --- drivers/iommu/amd/amd_iommu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Rafael J. Wysocki
On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman wrote: > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote: > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > > > Add a new (optional) field to denote the physical location of a device > > > in the system, and

Re: [PATCH v2 01/12] ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for NC

2020-06-30 Thread Hanjun Guo
On 2020/6/30 18:24, Lorenzo Pieralisi wrote: On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote: [...] For devices that aren't described in the DSDT - IORT translations are determined by their ACPI parent device. Do you see/Have you found any issue with this approach ? The spec says

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Robin Murphy
On 2020-06-30 09:19, Jon Hunter wrote: On 30/06/2020 01:10, Krishna Reddy wrote: NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave IOVA accesses across them. Add NVIDIA implementation for dual ARM MMU-500s and add new compatible string for Tegra194 SoC SMMU topology. There

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Greg Kroah-Hartman
On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote: > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman > wrote: > > > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote: > > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > > > > Add a new (optional)

Re: [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks

2020-06-30 Thread Jon Hunter
On 30/06/2020 13:13, Robin Murphy wrote: > On 2020-06-30 09:37, Jon Hunter wrote: >> >> On 30/06/2020 01:10, Krishna Reddy wrote: >>> Add global/context fault hooks to allow NVIDIA SMMU implementation >>> handle faults across multiple SMMUs. >> >> Nit ... this is not just for NVIDIA, but this

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Greg Kroah-Hartman
On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote: > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > > Add a new (optional) field to denote the physical location of a device > > in the system, and expose it in sysfs. This was discussed here: > >

Re: [PATCH net] xsk: remove cheap_dma optimization

2020-06-30 Thread Daniel Borkmann
On 6/30/20 7:07 AM, Christoph Hellwig wrote: On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote: On 6/29/20 5:10 PM, Björn Töpel wrote: On 2020-06-29 15:52, Daniel Borkmann wrote: Ok, fair enough, please work with DMA folks to get this properly integrated and restored then.

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 15:53, Robin Murphy wrote: > On 2020-06-30 09:19, Jon Hunter wrote: >> >> On 30/06/2020 01:10, Krishna Reddy wrote: >>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave >>> IOVA accesses across them. >>> Add NVIDIA implementation for dual ARM MMU-500s and add new

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 17:32, Jon Hunter wrote: > On 30/06/2020 17:23, Krishna Reddy wrote: +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device +*smmu) { + unsigned int i; >> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) { + struct resource *res;

Re: [PATCH 4/7] iommu/vt-d: Handle non-page aligned address

2020-06-30 Thread Jacob Pan
On Thu, 25 Jun 2020 18:05:52 +0800 Lu Baolu wrote: > Hi, > > On 2020/6/23 23:43, Jacob Pan wrote: > > From: Liu Yi L > > > > Address information for device TLB invalidation comes from userspace > > when device is directly assigned to a guest with vIOMMU support. > > VT-d requires page aligned

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 18:16, Krishna Reddy wrote: >> OK, well I see what you are saying, but if we intended to support all 3 for >> Tegra194, then we should ensure all 3 are initialised correctly. > > The driver intend to support up to 3 instances. It doesn't really mandate > that all three instances

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Rafael J. Wysocki
On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman wrote: > > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote: > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman > > wrote: > > > > > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote: > > > > On Mon, Jun 29,

Re: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Jon Hunter
On 30/06/2020 17:23, Krishna Reddy wrote: >>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device >>> +*smmu) { >>> + unsigned int i; > >>> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) { >>> + struct resource *res; >>> + >>> + res =

Re: [PATCH 6/7] iommu/vt-d: Warn on out-of-range invalidation address

2020-06-30 Thread Jacob Pan
On Thu, 25 Jun 2020 18:10:43 +0800 Lu Baolu wrote: > Hi, > > On 2020/6/23 23:43, Jacob Pan wrote: > > For guest requested IOTLB invalidation, address and mask are > > provided as part of the invalidation data. VT-d HW silently ignores > > any address bits below the mask. SW shall also allow

Re: [PATCH] iommu/amd: Fix event counter availability check

2020-06-30 Thread Alexander Monakov
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote: > > > On 6/1/20 4:01 PM, Alexander Monakov wrote: > > > > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote: > > > > > > > > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches > > > > > > resolves the issue. This is the earliest point

Re: [PATCH 1/2] iommu: Add iommu_group_get/set_domain()

2020-06-30 Thread Robin Murphy
On 2020-06-30 02:03, Lu Baolu wrote: Hi Robin, On 6/29/20 7:56 PM, Robin Murphy wrote: On 2020-06-27 04:15, Lu Baolu wrote: The hardware assistant vfio mediated device is a use case of iommu aux-domain. The interactions between vfio/mdev and iommu during mdev creation and passthr are: -

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Krishna Reddy
>OK, well I see what you are saying, but if we intended to support all 3 for >Tegra194, then we should ensure all 3 are initialised correctly. The driver intend to support up to 3 instances. It doesn't really mandate that all three instances be present in same DT node. Each mmio aperture in

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Krishna Reddy
>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device >> +*smmu) { >> +unsigned int i; >> +for (i = 1; i < MAX_SMMU_INSTANCES; i++) { >> +struct resource *res; >> + >> +res = platform_get_resource(pdev, IORESOURCE_MEM, i); >> +if

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Krishna Reddy
>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave >> IOVA accesses across them. >> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible >> string for Tegra194 SoC SMMU topology. >There is no description here of the 3rd SMMU that you mention below. >I think

Re: [PATCH v3 1/5] docs: IOMMU user API

2020-06-30 Thread Jacob Pan
On Tue, 30 Jun 2020 02:52:45 + "Tian, Kevin" wrote: > > From: Jacob Pan > > Sent: Tuesday, June 30, 2020 7:05 AM > > > > On Fri, 26 Jun 2020 16:19:23 -0600 > > Alex Williamson wrote: > > > > > On Tue, 23 Jun 2020 10:03:53 -0700 > > > Jacob Pan wrote: > > > > > > > IOMMU UAPI is newly

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Greg Kroah-Hartman
On Tue, Jun 30, 2020 at 06:08:31PM +0200, Rafael J. Wysocki wrote: > On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman > wrote: > > > > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote: > > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > On

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

2020-06-30 Thread Saravana Kannan via iommu
On Mon, Jun 29, 2020 at 9:49 PM Rajat Jain wrote: > > Add a new (optional) field to denote the physical location of a device > in the system, and expose it in sysfs. This was discussed here: > https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/ > > (The primary choice for

Re: the XSK buffer pool needs be to reverted

2020-06-30 Thread Jonathan Lemon
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote: > On 2020-06-27 08:02, Christoph Hellwig wrote: > > On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote: > > > On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote: > > > > > > > > Note that this is somewhat

[PATCH v2 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory

2020-06-30 Thread Jerry Snitselaar
Move Intel Kconfig and Makefile bits down into intel directory with the rest of the Intel specific files. Cc: Joerg Roedel Cc: Lu Baolu Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig| 86 +--- drivers/iommu/Makefile | 8 +---

[PATCH v2 2/2] iommu/amd: Move Kconfig and Makefile bits down into amd directory

2020-06-30 Thread Jerry Snitselaar
Move AMD Kconfig and Makefile bits down into the amd directory with the rest of the AMD specific files. Cc: Joerg Roedel Cc: Suravee Suthikulpanit Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig | 45 +- drivers/iommu/Makefile | 5 +

[PATCH v2 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories

2020-06-30 Thread Jerry Snitselaar
This patchset imeplements the suggestion from Linus to move the Kconfig and Makefile bits for AMD and Intel into their respective directories. v2: Rebase against v5.8-rc3. Dropped ---help--- changes from Kconfig as that was dealt with in systemwide cleanup. Jerry Snitselaar (2):

Re: [PATCH v2 10/12] of/irq: Make of_msi_map_rid() PCI bus agnostic

2020-06-30 Thread Rob Herring
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi wrote: > > There is nothing PCI bus specific in the of_msi_map_rid() > implementation other than the requester ID tag for the input > ID space. Rename requester ID to a more generic ID so that > the translation code can be used by all busses that

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2020-06-30 Thread Krishna Reddy
>> The driver intend to support up to 3 instances. It doesn't really mandate >> that all three instances be present in same DT node. >> Each mmio aperture in "reg" property is an instance here. reg = >> , , ; The reg can have >> all three or less and driver just configures based on reg and it

Re: [PATCH v2 07/12] of/device: Add input id to of_dma_configure()

2020-06-30 Thread Rob Herring
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi wrote: > > Devices sitting on proprietary busses have a device ID space that > is owned by the respective bus and related firmware bindings. In order > to let the generic OF layer handle the input translations to > an IOMMU id, for such busses the

Re: [PATCH v2 09/12] of/irq: make of_msi_map_get_device_domain() bus agnostic

2020-06-30 Thread Rob Herring
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi wrote: > > From: Diana Craciun > > of_msi_map_get_device_domain() is PCI specific but it need not be and > can be easily changed to be bus agnostic in order to be used by other > busses by adding an IRQ domain bus token as an input parameter. > >

Re: [PATCH v2 08/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus

2020-06-30 Thread Rob Herring
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi wrote: > > From: Laurentiu Tudor > > The existing bindings cannot be used to specify the relationship > between fsl-mc devices and GIC ITSes. > Add a generic binding for mapping fsl-mc devices to GIC ITSes, using > msi-map property. > In

[PATCH v2 5/7] iommu/vt-d: Fix devTLB flush for vSVA

2020-06-30 Thread Jacob Pan
From: Liu Yi L For guest SVA usage, in order to optimize for less VMEXIT, guest request of IOTLB flush also includes device TLB. On the host side, IOMMU driver performs IOTLB and implicit devTLB invalidation. When PASID-selective granularity is requested by the guest we need to derive the

[PATCH v2 2/7] iommu/vt-d: Remove global page support in devTLB flush

2020-06-30 Thread Jacob Pan
Global pages support is removed from VT-d spec 3.0 for dev TLB invalidation. This patch is to remove the bits for vSVA. Similar change already made for the native SVA. See the link below. Link: https://lkml.org/lkml/2019/8/26/651 Acked-by: Lu Baolu Signed-off-by: Jacob Pan ---

[PATCH v2 7/7] iommu/vt-d: Disable multiple GPASID-dev bind

2020-06-30 Thread Jacob Pan
For the unlikely use case where multiple aux domains from the same pdev are attached to a single guest and then bound to a single process (thus same PASID) within that guest, we cannot easily support this case by refcounting the number of users. As there is only one SL page table per PASID while

[PATCH v2 1/7] iommu/vt-d: Enforce PASID devTLB field mask

2020-06-30 Thread Jacob Pan
From: Liu Yi L Set proper masks to avoid invalid input spillover to reserved bits. Acked-by: Lu Baolu Signed-off-by: Liu Yi L Signed-off-by: Jacob Pan --- include/linux/intel-iommu.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/intel-iommu.h

[PATCH v2 3/7] iommu/vt-d: Fix PASID devTLB invalidation

2020-06-30 Thread Jacob Pan
DevTLB flush can be used for both DMA request with and without PASIDs. The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA usage. This patch adds a check for PASID value such that devTLB flush with PASID is used for SVA case. This is more efficient in that multiple PASIDs can

[PATCH v2 6/7] iommu/vt-d: Warn on out-of-range invalidation address

2020-06-30 Thread Jacob Pan
For guest requested IOTLB invalidation, address and mask are provided as part of the invalidation data. VT-d HW silently ignores any address bits below the mask. SW shall also allow such case but give warning if address does not align with the mask. This patch relax the fault handling from error

[PATCH v2 0/7] iommu/vt-d: Misc tweaks and fixes for vSVA

2020-06-30 Thread Jacob Pan
Hi Baolu and all, This is a series to address some of the issues we found in vSVA support. Most of the patches deal with exception handling, we also removed some bits that are not currently supported. Many thanks to Kevin Tian's review. Jacob & Yi Changelog: v2 Address reviews from Baolu

[PATCH v2 4/7] iommu/vt-d: Handle non-page aligned address

2020-06-30 Thread Jacob Pan
From: Liu Yi L Address information for device TLB invalidation comes from userspace when device is directly assigned to a guest with vIOMMU support. VT-d requires page aligned address. This patch checks and enforce address to be page aligned, otherwise reserved bits can be set in the

Re: [PATCH 6/7] iommu/vt-d: Warn on out-of-range invalidation address

2020-06-30 Thread Lu Baolu
Hi Jacob, On 7/1/20 1:34 AM, Jacob Pan wrote: On Thu, 25 Jun 2020 18:10:43 +0800 Lu Baolu wrote: Hi, On 2020/6/23 23:43, Jacob Pan wrote: For guest requested IOTLB invalidation, address and mask are provided as part of the invalidation data. VT-d HW silently ignores any address bits below

[PATCH v2 0/3] iommu/amd: I/O VA address limits

2020-06-30 Thread Sebastian Ott via iommu
The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses that can be handled by the IOMMUs in the system. Parse that data from the IVRS header to provide aperture information for DMA mappings and users of the iommu API. Changes for V2: - use limits in iommu_setup_dma_ops()

[PATCH v2 3/3] iommu/amd: Actually enforce geometry aperture

2020-06-30 Thread Sebastian Ott via iommu
Add a check to enforce that I/O virtual addresses picked by iommu API users stay within the domains geometry aperture. Signed-off-by: Sebastian Ott Cc: Benjamin Serebrin Cc: Filippo Sironi CR: https://code.amazon.com/reviews/CR-26408388 --- drivers/iommu/amd/iommu.c | 9 - 1 file

[PATCH v2 1/3] iommu/amd: Parse supported address sizes from IVRS

2020-06-30 Thread Sebastian Ott via iommu
The IVRS ACPI table specifies maximum address sizes for i/o virtual addresses that can be handled by the IOMMUs in the system. Parse that data from the IVRS header so that it can be considered in limiting the IO aperture (in subsequent patches). Based on prior work by Marius Hillenbrand. Link:

[PATCH v2 2/3] iommu/amd: Restrict aperture for domains to conform with IVRS

2020-06-30 Thread Sebastian Ott via iommu
The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses. When allocating new protection domains that perform translation, propagate these limits as the domain's geometry / aperture. Based on prior work by Marius Hillenbrand. Signed-off-by: Sebastian Ott Cc: Benjamin

[PATCH v5 09/12] x86/process: Clear PASID state for a newly forked/cloned thread

2020-06-30 Thread Fenghua Yu
The PASID state has to be cleared on forks, since the child has a different address space. The PASID is also cleared for thread clone. While it would be correct to inherit the PASID in this case, it is unknown whether the new task will use ENQCMD. Giving it the PASID "just in case" would have the

[PATCH v5 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

2020-06-30 Thread Fenghua Yu
From: Ashok Raj ENQCMD and Data Streaming Accelerator (DSA) and all of their associated features are a complicated stack with lots of interconnected pieces. This documentation provides a big picture overview for all of the features. Signed-off-by: Ashok Raj Co-developed-by: Fenghua Yu

[PATCH v5 01/12] iommu: Change type of pasid to u32

2020-06-30 Thread Fenghua Yu
PASID is defined as a few different types in iommu including "int", "u32", and "unsigned int". To be consistent and to match with uapi definitions, define PASID and its variations (e.g. max PASID) as "u32". "u32" is also shorter and a little more explicit than "unsigned int". No PASID type change

[PATCH v5 08/12] fork: Clear PASID for new mm

2020-06-30 Thread Fenghua Yu
When a new mm is created, its PASID should be cleared, i.e. the PASID is initialized to its init state 0 on both ARM and X86. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- v2: - Add this patch to initialize PASID value for a new mm. include/linux/mm_types.h | 2 ++ kernel/fork.c

[PATCH v5 04/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions

2020-06-30 Thread Fenghua Yu
Work submission instruction comes in two flavors. ENQCMD can be called both in ring 3 and ring 0 and always uses the contents of PASID MSR when shipping the command to the device. ENQCMDS allows a kernel driver to submit commands on behalf of a user process. The driver supplies the PASID value in

  1   2   >