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

2020-07-01 Thread Oliver O'Halloran
On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote: > > *snip* > > > > I guess it would make sense to have an attribute for user space to > > > write to in order to make the kernel reject device plug-in events > > > coming from a given port or connector, but the kernel has no reliable > > > means to

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

2020-07-01 Thread Lu Baolu
Hi Robin, On 7/1/20 8:18 PM, Robin Murphy wrote: On 2020-07-01 08:32, Lu Baolu wrote: Hi Robin, On 2020/7/1 0:51, Robin Murphy wrote: 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

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

2020-07-01 Thread Lu Baolu
Hello, On 7/1/20 8:18 PM, Robin Murphy wrote: On 2020-07-01 08:32, Lu Baolu wrote: Hi Robin, On 2020/7/1 0:51, Robin Murphy wrote: 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

[PATCH AUTOSEL 5.4 25/40] iommu/vt-d: Don't apply gfx quirks to untrusted devices

2020-07-01 Thread Sasha Levin
From: Rajat Jain [ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ] Currently, an external malicious PCI device can masquerade the VID:PID of faulty gfx devices, and thus apply iommu quirks to effectively disable the IOMMU restrictions for itself. Thus we need to ensure that the

[PATCH AUTOSEL 5.7 32/53] iommu/vt-d: Don't apply gfx quirks to untrusted devices

2020-07-01 Thread Sasha Levin
From: Rajat Jain [ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ] Currently, an external malicious PCI device can masquerade the VID:PID of faulty gfx devices, and thus apply iommu quirks to effectively disable the IOMMU restrictions for itself. Thus we need to ensure that the

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

2020-07-01 Thread Lu Baolu
On 7/1/20 11:33 PM, 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 such case but give warning if address does not align with the mask. This

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

2020-07-01 Thread Lu Baolu
On 7/1/20 11:33 PM, Jacob Pan wrote: 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

Re: [PATCH] xen: introduce xen_vring_use_dma

2020-07-01 Thread Michael S. Tsirkin
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote: > Would you be in favor of a more flexible check along the lines of the > one proposed in the patch that started this thread: > > if (xen_vring_use_dma()) > return true; > > > xen_vring_use_dma would be

[PATCH v6 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-01 Thread Jim Quinlan via iommu
The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking.

[PATCH v6 00/12] PCI: brcmstb: enable PCIe for STB chips

2020-07-01 Thread Jim Quinlan via iommu
Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. v6: Commit "device core: Introduce DMA range map": --

Re: [PATCH] xen: introduce xen_vring_use_dma

2020-07-01 Thread Michael S. Tsirkin
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote: > On Wed, 1 Jul 2020, Christoph Hellwig wrote: > > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote: > > > > I could imagine some future Xen hosts setting a flag somewhere in the > > > > platform capability

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

2020-07-01 Thread Krishna Reddy
On 01/07/2020 20:00, Krishna Reddy wrote: >> +items: >> + - enum: >> + - nvdia,tegra194-smmu >> + - const: arm,mmu-500 > Is the fallback compatible appropriate here? If software treats this as a > standard MMU-500 it will only

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

2020-07-01 Thread Jon Hunter
On 01/07/2020 20:00, Krishna Reddy wrote: > +items: > + - enum: > + - nvdia,tegra194-smmu > + - const: arm,mmu-500 >>> Is the fallback compatible appropriate here? If software treats this as a standard MMU-500 it will only program

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

2020-07-01 Thread Krishna Reddy
>> With shared irq line, the context fault identification is not optimal >> already. Reading all the context banks all the time can be additional mmio >> read overhead. But, it may not hurt the real use cases as these happen only >> when there are bugs. >Right, I did ponder the idea of a

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

2020-07-01 Thread Robin Murphy
On 2020-07-01 19:48, Krishna Reddy wrote: +for (inst = 0; inst < nvidia_smmu->num_inst; inst++) { +irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst); +if (irq_ret == IRQ_HANDLED) +return irq_ret; Any chance there could be more than one

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

2020-07-01 Thread Krishna Reddy
>Yeah, I realised later last night that this probably originated from forking >the whole driver downstream. But even then you could have treated the other >one as a separate nsmmu with a single instance ;) True, But the initial nvidia implementation had limitation that it can only handle one

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

2020-07-01 Thread Robin Murphy
On 2020-07-01 19:47, Jon Hunter wrote: On 01/07/2020 19:28, Krishna Reddy wrote: + - description: NVIDIA SoCs that use more than one "arm,mmu-500" Hmm, there must be a better way to word that to express that it only applies to the sets of SMMUs that must be programmed identically, and

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

2020-07-01 Thread Krishna Reddy
+items: + - enum: + - nvdia,tegra194-smmu + - const: arm,mmu-500 > > >>> Is the fallback compatible appropriate here? If software treats this as a >>> standard MMU-500 it will only program the first instance (because the >>> second isn't

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

2020-07-01 Thread Robin Murphy
On 2020-07-01 19:18, Krishna Reddy wrote: + * When Linux kernel supports multiple SMMU devices, the SMMU device +used for + * isochornous HW devices should be added as a separate ARM MMU-500 +device + * in DT and be programmed independently for efficient TLB invalidates. I don't understand

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

2020-07-01 Thread Krishna Reddy
>>> +for (inst = 0; inst < nvidia_smmu->num_inst; inst++) { >>> +irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst); >>> +if (irq_ret == IRQ_HANDLED) >>> +return irq_ret; >> >> Any chance there could be more than one SMMU faulting by the time

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

2020-07-01 Thread Jon Hunter
On 01/07/2020 19:28, Krishna Reddy wrote: >>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500" >> Hmm, there must be a better way to word that to express that it only applies >> to the sets of SMMUs that must be programmed identically, and not any other >> independent

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

2020-07-01 Thread Krishna Reddy
>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500" > Hmm, there must be a better way to word that to express that it only applies > to the sets of SMMUs that must be programmed identically, and not any other > independent MMU-500s that might also happen to be in the same

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

2020-07-01 Thread Krishna Reddy
>> + * When Linux kernel supports multiple SMMU devices, the SMMU device >> +used for >> + * isochornous HW devices should be added as a separate ARM MMU-500 >> +device >> + * in DT and be programmed independently for efficient TLB invalidates. >I don't understand the "When" there - the driver

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

2020-07-01 Thread Rajat Jain via iommu
Hello, On Tue, Jun 30, 2020 at 10:00 AM Greg Kroah-Hartman wrote: > > 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

Re: [PATCH] xen: introduce xen_vring_use_dma

2020-07-01 Thread Stefano Stabellini
On Wed, 1 Jul 2020, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote: > > > I could imagine some future Xen hosts setting a flag somewhere in the > > > platform capability saying "no xen specific flag, rely on > > > "VIRTIO_F_ACCESS_PLATFORM". Then you

Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-07-01 Thread Laurentiu Tudor
On 6/19/2020 11:20 AM, Lorenzo Pieralisi wrote: > From: Makarand Pawagi > > Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to > extract memory and other resources. > > Interrupt (GIC ITS) information is extracted from the MADT table > by

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

2020-07-01 Thread Robin Murphy
On 2020-06-30 14:04, Hanjun Guo wrote: 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

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

2020-07-01 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

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

2020-07-01 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 v3 3/7] iommu/vt-d: Fix PASID devTLB invalidation

2020-07-01 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 v3 0/7] iommu/vt-d: Misc tweaks and fixes for vSVA

2020-07-01 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: v3 - Use pr_err instead of

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

2020-07-01 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 v3 5/7] iommu/vt-d: Fix devTLB flush for vSVA

2020-07-01 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 v3 2/7] iommu/vt-d: Remove global page support in devTLB flush

2020-07-01 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 v3 7/7] iommu/vt-d: Disable multiple GPASID-dev bind

2020-07-01 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

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

2020-07-01 Thread Matthias Brugger
On 30/06/2020 12:59, chao hao wrote: > 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

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

2020-07-01 Thread Matthias Brugger
On 30/06/2020 12:53, chao hao wrote: > 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

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

2020-07-01 Thread Jacob Pan
On Wed, 1 Jul 2020 08:49:54 +0800 Lu Baolu wrote: > Hi Jacob, > > On 7/1/20 5:07 AM, Jacob Pan wrote: > > 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

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

2020-07-01 Thread Jacob Pan
On Wed, 1 Jul 2020 09:45:40 +0800 Lu Baolu wrote: > 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 >

Re: [PATCH] xen: introduce xen_vring_use_dma

2020-07-01 Thread Christoph Hellwig
On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote: > > I could imagine some future Xen hosts setting a flag somewhere in the > > platform capability saying "no xen specific flag, rely on > > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > > How about that? >

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

2020-07-01 Thread Robin Murphy
On 2020-07-01 08:32, Lu Baolu wrote: Hi Robin, On 2020/7/1 0:51, Robin Murphy wrote: 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.

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

2020-07-01 Thread Will Deacon
On Wed, Jul 01, 2020 at 12:40:50AM -0700, Bjorn Andersson wrote: > On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote: > > at that point I'm inclined to suggest we give up and stop trying to > > drive these things with arm-smmu. The XZR thing was bad enough, but if > > they're not even going to

Re: [PATCH v3 00/34] iommu: Move iommu_group setup to IOMMU core code

2020-07-01 Thread Robin Murphy
On 2020-07-01 01:40, Qian Cai wrote: Looks like this patchset introduced an use-after-free on arm-smmu-v3. Reproduced using mlx5, # echo 1 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs # echo 0 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs The .config,

Re: [PATCH net] xsk: remove cheap_dma optimization

2020-07-01 Thread Björn Töpel
On 2020-06-29 17:41, Robin Murphy wrote: On 2020-06-28 18:16, Björn Töpel wrote: [...]> Somewhat related to the DMA API; It would have performance benefits for AF_XDP if the DMA range of the mapped memory was linear, i.e. by IOMMU utilization. I've started hacking a thing a little bit, but it

Re: [PATCH v9 0/7] iommu/arm-smmu: Enable split pagetable support

2020-07-01 Thread Sai Prakash Ranjan
Hi Will, Robin, On 2020-06-27 01:30, Jordan Crouse wrote: Another iteration of the split-pagetable support for arm-smmu and the Adreno GPU SMMU. After email discussions [1] we opted to make a arm-smmu implementation for specifically for the Adreno GPU and use that to enable split pagetable

Re: the XSK buffer pool needs be to reverted

2020-07-01 Thread Robin Murphy
On 2020-06-30 20:08, Jonathan Lemon wrote: 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

Re: [PATCH v9 3/4] dt-bindings: arm-smmu: add binding for Tegra194 SMMU

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

Re: [PATCH v9 2/4] iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage

2020-07-01 Thread Jon Hunter
On 01/07/2020 00:57, Krishna Reddy wrote: > NVIDIA's Tegra194 SoC has three ARM MMU-500 instances. > It uses two of ARM MMU-500s together to interleave IOVA accesses > across them and must be programmed identically. > The third SMMU instance is used as a regular ARM MMU-500 and it > can either

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

2020-07-01 Thread Bjorn Andersson
On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote: > On 2020-06-02 07:32, Bjorn Andersson wrote: > > On Wed 27 May 04:03 PDT 2020, Will Deacon wrote: > > > > > Hi John, Bjorn, > > > > > > On Tue, May 26, 2020 at 01:34:45PM -0700, John Stultz wrote: > > > > On Thu, May 14, 2020 at 12:34 PM

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

2020-07-01 Thread Lu Baolu
Hi Robin, On 2020/7/1 0:51, Robin Murphy wrote: 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