iommu/vt-d: Cure VF irqdomain hickup

2020-11-12 Thread Thomas Gleixner
The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain assigned and then issues compat MSI messages which get caught by the interrupt remapping unit. Cure that

Re: remove dma_virt_ops v2

2020-11-12 Thread Jason Gunthorpe
On Fri, Nov 06, 2020 at 07:19:31PM +0100, Christoph Hellwig wrote: > Hi Jason, > > this series switches the RDMA core to opencode the special case of > devices bypassing the DMA mapping in the RDMA ULPs. The virt ops > have caused a bit of trouble due to the P2P code node working with > them due

Re: remove dma_virt_ops v2

2020-11-12 Thread Christoph Hellwig
On Thu, Nov 12, 2020 at 12:59:35PM -0400, Jason Gunthorpe wrote: > RMDA/sw: Don't allow drivers using dma_virt_ops on highmem configs I think this one actually is something needed in 5.10 and -stable. ___ iommu mailing list

Re: remove dma_virt_ops v2

2020-11-12 Thread Jason Gunthorpe
On Thu, Nov 12, 2020 at 06:09:56PM +0100, Christoph Hellwig wrote: > On Thu, Nov 12, 2020 at 12:59:35PM -0400, Jason Gunthorpe wrote: > > RMDA/sw: Don't allow drivers using dma_virt_ops on highmem configs > > I think this one actually is something needed in 5.10 and -stable. Done, I added a

Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-11-12 Thread John Stultz
On Thu, Nov 12, 2020 at 9:37 AM Will Deacon wrote: > On Tue, Nov 10, 2020 at 10:51:46AM -0800, John Stultz wrote: > > On Tue, Nov 10, 2020 at 5:35 AM Linus Walleij > > wrote: > > > On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > > > > > > > Allow the qcom_scm driver to be loadable as a

Re: remove dma_virt_ops v2

2020-11-12 Thread santosh . shilimkar
+ Ka-Cheong On 11/12/20 5:23 AM, Jason Gunthorpe wrote: On Thu, Nov 12, 2020 at 10:40:30AM +0100, Christoph Hellwig wrote: ping? On Fri, Nov 06, 2020 at 07:19:31PM +0100, Christoph Hellwig wrote: Hi Jason, this series switches the RDMA core to opencode the special case of devices bypassing

Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-11-12 Thread Will Deacon
On Tue, Nov 10, 2020 at 10:51:46AM -0800, John Stultz wrote: > On Tue, Nov 10, 2020 at 5:35 AM Linus Walleij > wrote: > > On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote: > > > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > ... > > I applied this patch to the

Re: iommu/vt-d: Cure VF irqdomain hickup

2020-11-12 Thread Thomas Gleixner
On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote: > The recent changes to store the MSI irqdomain pointer in struct device > missed that Intel DMAR does not register virtual function devices. Due to > that a VF device gets the plain PCI-MSI domain assigned and then issues > compat MSI messages

[RESEND][PATCH 2/2] iommu: Avoid crash if iommu_group is null

2020-11-12 Thread John Stultz
In trying to handle a possible driver probe ordering issue brought up by Robin Murphy, I ran across a separate null pointer crash in the iommu core in iommu_group_remove_device(): [2.732803] dwc3-qcom a6f8800.usb: failed to get usb-ddr path: -517 [2.739281] Unable to handle kernel NULL

[RESEND][PATCH 1/2] arm-smmu-qcom: Ensure the qcom_scm driver has finished probing

2020-11-12 Thread John Stultz
Robin Murphy pointed out that if the arm-smmu driver probes before the qcom_scm driver, we may call qcom_scm_qsmmu500_wait_safe_toggle() before the __scm is initialized. Now, getting this to happen is a bit contrived, as in my efforts it required enabling asynchronous probing for both drivers,

Re: [PATCH v8 5/9] ACPI/IORT: Enable stall support for platform devices

2020-11-12 Thread Hanjun Guo
On 2020/11/12 20:55, Jean-Philippe Brucker wrote: Copy the "Stall supported" bit, that tells whether a platform device supports stall, into the fwspec struct. Signed-off-by: Jean-Philippe Brucker Acked-by: Hanjun Guo ___ iommu mailing list

Re: [PATCH v3 00/14] iommu/amd: Add Generic IO Page Table Framework Support

2020-11-12 Thread Suravee Suthikulpanit
Joerg, Please ignore to include the V3. I am working on V4 to resubmit. Thank you, Suravee On 11/11/20 10:10 AM, Suravee Suthikulpanit wrote: Hi Joerg, Do you have any update on this series? Thanks, Suravee On 11/2/20 10:16 AM, Suravee Suthikulpanit wrote: Joerg, You mentioned to remind

Re: iommu/vt-d: Cure VF irqdomain hickup

2020-11-12 Thread Lu Baolu
Hi Thomas, On 2020/11/13 3:15, Thomas Gleixner wrote: The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain assigned and then issues compat MSI messages

Re: [PATCH v2] iommu/vt-d: avoid unnecessory panic if iommu init fail in tboot system

2020-11-12 Thread Lukasz Hawrylko
On Tue, 2020-11-10 at 15:19 +0800, Zhenzhong Duan wrote: > "intel_iommu=off" command line is used to disable iommu but iommu is force > enabled in a tboot system for security reason. > > However for better performance on high speed network device, a new option > "intel_iommu=tboot_noforce" is

Re: [PATCHv7 2/7] iommu/arm-smmu: Add domain attribute for system cache

2020-11-12 Thread Will Deacon
On Wed, Nov 11, 2020 at 12:10:50PM +0530, Sai Prakash Ranjan wrote: > On 2020-11-10 17:48, Will Deacon wrote: > > On Fri, Oct 30, 2020 at 02:53:09PM +0530, Sai Prakash Ranjan wrote: > > > Add iommu domain attribute for using system cache aka last level > > > cache by client drivers like GPU to set

Re: [PATCHv7 1/7] iommu/io-pgtable-arm: Add support to use system cache

2020-11-12 Thread Will Deacon
On Wed, Nov 11, 2020 at 11:32:42AM +0530, Sai Prakash Ranjan wrote: > On 2020-11-10 17:48, Will Deacon wrote: > > On Fri, Oct 30, 2020 at 02:53:08PM +0530, Sai Prakash Ranjan wrote: > > > Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the > > > attributes set in TCR for the page table walker

Re: remove dma_virt_ops v2

2020-11-12 Thread Christoph Hellwig
ping? On Fri, Nov 06, 2020 at 07:19:31PM +0100, Christoph Hellwig wrote: > Hi Jason, > > this series switches the RDMA core to opencode the special case of > devices bypassing the DMA mapping in the RDMA ULPs. The virt ops > have caused a bit of trouble due to the P2P code node working with >

Re: REGRESSION: Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI

2020-11-12 Thread Thomas Gleixner
Jason, (trimmed CC list a bit) On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote: > On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote: > They were unable to bisect further into the series because some of the > interior commits don't boot :( > > When we try to load the mlx5 driver

REGRESSION: Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI

2020-11-12 Thread Jason Gunthorpe
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote: > This is the second version of providing a base to support device MSI (non > PCI based) and on top of that support for IMS (Interrupt Message Storm) > based devices in a halfways architecture independent way. Hi Thomas, Our test

[PATCH v8 8/9] PCI/ATS: Export PRI functions

2020-11-12 Thread Jean-Philippe Brucker
The SMMUv3 driver uses pci_{enable,disable}_pri() and related functions. Export those functions to allow the driver to be built as a module. Acked-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Jean-Philippe Brucker --- drivers/pci/ats.c | 4 1 file changed, 4

[PATCH v8 7/9] PCI/ATS: Add PRI stubs

2020-11-12 Thread Jean-Philippe Brucker
The SMMUv3 driver, which can be built without CONFIG_PCI, will soon gain support for PRI. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove unused PRI and PASID stubs") to re-introduce the PRI stubs, and avoid adding more #ifdefs to the SMMU driver. Acked-by: Bjorn Helgaas Reviewed-by:

[PATCH v8 0/9] iommu: I/O page faults for SMMUv3

2020-11-12 Thread Jean-Philippe Brucker
Add support for stall and PRI to the SMMUv3 driver, along with a common I/O Page Fault handler. These patches were last sent as part of v7 of the larger SVA series [1]. Main changes since v7: * Dropped CONFIG_IOMMU_PAGE_FAULT, reuse CONFIG_IOMMU_SVA_LIB instead. * Extracted devicetree support

[PATCH v8 9/9] iommu/arm-smmu-v3: Add support for PRI

2020-11-12 Thread Jean-Philippe Brucker
For PCI devices that support it, enable the PRI capability and handle PRI Page Requests with the generic fault handler. It is enabled on demand by iommu_sva_device_init(). Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 20 +-

[PATCH v8 3/9] dt-bindings: document stall property for IOMMU masters

2020-11-12 Thread Jean-Philippe Brucker
On ARM systems, some platform devices behind an IOMMU may support stall, which is the ability to recover from page faults. Let the firmware tell us when a device supports stall. Reviewed-by: Rob Herring Signed-off-by: Jean-Philippe Brucker --- .../devicetree/bindings/iommu/iommu.txt|

[PATCH v8 5/9] ACPI/IORT: Enable stall support for platform devices

2020-11-12 Thread Jean-Philippe Brucker
Copy the "Stall supported" bit, that tells whether a platform device supports stall, into the fwspec struct. Signed-off-by: Jean-Philippe Brucker --- drivers/acpi/arm64/iort.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index

[PATCH v8 2/9] iommu/arm-smmu-v3: Maintain a SID->device structure

2020-11-12 Thread Jean-Philippe Brucker
When handling faults from the event or PRI queue, we need to find the struct device associated to a SID. Add a rb_tree to keep track of SIDs. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 161

[PATCH v8 6/9] iommu/arm-smmu-v3: Add stall support for platform devices

2020-11-12 Thread Jean-Philippe Brucker
The SMMU provides a Stall model for handling page faults in platform devices. It is similar to PCIe PRI, but doesn't require devices to have their own translation cache. Instead, faulting transactions are parked and the OS is given a chance to fix the page tables and retry the transaction. Enable

[PATCH v8 1/9] iommu: Add a page fault handler

2020-11-12 Thread Jean-Philippe Brucker
Some systems allow devices to handle I/O Page Faults in the core mm. For example systems implementing the PCIe PRI extension or Arm SMMU stall model. Infrastructure for reporting these recoverable page faults was added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device fault report

[PATCH v8 4/9] of/iommu: Support dma-can-stall property

2020-11-12 Thread Jean-Philippe Brucker
Copy the dma-can-stall property into the fwspec structure. Signed-off-by: Jean-Philippe Brucker --- include/linux/iommu.h| 2 ++ drivers/iommu/of_iommu.c | 5 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index

Re: remove dma_virt_ops v2

2020-11-12 Thread Jason Gunthorpe
On Thu, Nov 12, 2020 at 10:40:30AM +0100, Christoph Hellwig wrote: > ping? > > On Fri, Nov 06, 2020 at 07:19:31PM +0100, Christoph Hellwig wrote: > > Hi Jason, > > > > this series switches the RDMA core to opencode the special case of > > devices bypassing the DMA mapping in the RDMA ULPs. The

Re: [PATCH v2 04/17] iommu/hyperv: don't setup IRQ remapping when running as root

2020-11-12 Thread Vitaly Kuznetsov
Wei Liu writes: > The IOMMU code needs more work. We're sure for now the IRQ remapping > hooks are not applicable when Linux is the root. Super-nitpick: I would suggest we always say 'root partition' as 'root' has a 'slightly different' meaning in Linux and this commit message may sound

Re: REGRESSION: Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI

2020-11-12 Thread Thomas Gleixner
On Thu, Nov 12 2020 at 15:15, Thomas Gleixner wrote: > On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote: >> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote: >> They were unable to bisect further into the series because some of the >> interior commits don't boot :( >> >> When we

[PATCH v3 2/4] iommu/iova: Avoid double-negatives in magazine helpers

2020-11-12 Thread John Garry
A similar crash to the following could be observed if initial CPU rcache magazine allocations fail in init_iova_rcaches(): Unable to handle kernel NULL pointer dereference at virtual address Mem abort info: ESR = 0x9604 EC = 0x25: DABT (current EL), IL = 32 bits SET

[PATCH v3 4/4] iommu: avoid taking iova_rbtree_lock twice

2020-11-12 Thread John Garry
From: Cong Wang Both find_iova() and __free_iova() take iova_rbtree_lock, there is no reason to take and release it twice inside free_iova(). Fold them into one critical section by calling the unlock versions instead. Signed-off-by: Cong Wang Reviewed-by: Robin Murphy Signed-off-by: John

[PATCH v3 1/4] iommu/iova: Add free_all_cpu_cached_iovas()

2020-11-12 Thread John Garry
Add a helper function to free the CPU rcache for all online CPUs. There also exists a function of the same name in drivers/iommu/intel/iommu.c, but the parameters are different, and there should be no conflict. Signed-off-by: John Garry --- drivers/iommu/iova.c | 13 + 1 file

[PATCH v3 0/4] iommu/iova: Solve longterm IOVA issue

2020-11-12 Thread John Garry
This series contains a patch to solve the longterm IOVA issue which leizhen originally tried to address at [0]. A sieved kernel log is at the following, showing periodic dumps of IOVA sizes, per CPU and per depot bin, per IOVA size granule:

[PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

2020-11-12 Thread John Garry
Leizhen reported some time ago that IOVA performance may degrade over time [0], but unfortunately his solution to fix this problem was not given attention. To summarize, the issue is that as time goes by, the CPU rcache and depot rcache continue to grow. As such, IOVA RB tree access time also

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-12 Thread Nicolas Saenz Julienne
Hi Catalin, On Tue, 2020-11-10 at 18:17 +, Catalin Marinas wrote: > On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote: > > On Thu, 2020-11-05 at 16:11 +, James Morse wrote: > > > On 03/11/2020 17:31, Nicolas Saenz Julienne wrote: > > > > crashkernel might reserve