support range based offsets in dma-direct v3

2020-09-16 Thread Christoph Hellwig
Hi all, this series adds range-based offsets to the dma-direct implementation. The guts of the change are a patch from Jim with some modifications from me, but to do it nicely we need to ARM patches to prepare for it as well. Changes since v2: - fix a mismerge - return (phys_addr_t)-1 from

[PATCH 4/6] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

2020-09-16 Thread Christoph Hellwig
The DMA offset notifier can only be used if PHYS_OFFSET is at least KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit phys_addr_t. Currently the code compiles fine despite that, a pending change to the DMA offset handling would create a compiler warning for this case. Add an ifdef

Re: [PATCH v8 0/9] x86: tag application address space for devices

2020-09-16 Thread Joerg Roedel
On Tue, Sep 15, 2020 at 09:30:04AM -0700, Fenghua Yu wrote: > Ashok Raj (1): > Documentation/x86: Add documentation for SVA (Shared Virtual > Addressing) > > Fenghua Yu (7): > drm, iommu: Change type of pasid to u32 > iommu/vt-d: Change flags type to unsigned int in binding mm >

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jean-Philippe Brucker
On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, September 15, 2020 10:29 PM > > > > > Do they need a device at all? It's not clear to me why RID based > > > IOMMU management fits within vfio's scope, but PASID based does not. > > > > In

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-09-16 Thread Neil Armstrong
Hi Robin, On 16/09/2020 01:51, Robin Murphy wrote: > According to a downstream commit I found in the Khadas vendor kernel, > the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows > how to handle this properly) we should describe it as such. Otherwise > the mismatch leads to all

[PATCH 1/6] ARM/dma-mapping: remove a __arch_page_to_dma #error

2020-09-16 Thread Christoph Hellwig
The __arch_page_to_dma hook is long gone. Signed-off-by: Christoph Hellwig --- arch/arm/include/asm/dma-mapping.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index bdd80ddbca3451..70d95677656044 100644 ---

Re: [PATCH] dma-direct: Fix potential NULL pointer dereference

2020-09-16 Thread Christoph Hellwig
On Tue, Sep 15, 2020 at 04:46:17PM -0400, Thomas Tai wrote: > I tried out the suggested changes, and it successfully warned the null > pointer without panic. I notice that there are some places outside the > dma-direct, which calls dma_capable(). > >

[PATCH 5/6] usb: don't inherity DMA properties for USB devices

2020-09-16 Thread Christoph Hellwig
As the comment in usb_alloc_dev correctly states, drivers can't use the DMA API on usb device, and at least calling dma_set_mask on them is highly dangerous. Unlike what the comment states upper level drivers also can't really use the presence of a dma mask to check for DMA support, as the

Re: [PATCH 6/6] dma-mapping: introduce DMA range map, supplanting dma_pfn_offset

2020-09-16 Thread Christoph Hellwig
On Tue, Sep 15, 2020 at 01:55:01PM -0600, Mathieu Poirier wrote: > That did the trick - the stm32 platform driver's probe() function completes > and > the remote processor is operatinal. > > That being said the value returned by function dma_to_pfn() > is 0x137fff in the original code and

[PATCH 2/6] ARM/dma-mapping: remove dma_to_virt

2020-09-16 Thread Christoph Hellwig
dma_to_virt is entirely unused, remove it. Signed-off-by: Christoph Hellwig --- arch/arm/include/asm/dma-mapping.h| 18 +- arch/arm/mach-omap1/include/mach/memory.h | 4 2 files changed, 1 insertion(+), 21 deletions(-) diff --git

[PATCH 3/6] ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.h

2020-09-16 Thread Christoph Hellwig
Move the helpers to translate to and from direct mapping DMA addresses to dma-direct.h. This not only is the most logical place, but the new placement also avoids dependency loops with pending commits. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy --- arch/arm/common/dmabounce.c

[PATCH 6/6] dma-mapping: introduce DMA range map, supplanting dma_pfn_offset

2020-09-16 Thread Christoph Hellwig
From: Jim Quinlan 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

Re: [PATCH] iommu/amd: fix interrupt remapping for avic

2020-09-16 Thread Suravee Suthikulpanit
On 9/15/20 8:19 PM, Joao Martins wrote: On 9/15/20 1:30 PM, Suravee Suthikulpanit wrote: On 9/15/20 6:25 PM, Maxim Levitsky wrote: On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote: Could you please try with the following patch instead? --- a/drivers/iommu/amd/iommu.c +++

Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings

2020-09-16 Thread Laurentiu Tudor
On 9/4/2020 6:55 PM, Bjorn Andersson wrote: > Based on previous attempts and discussions this is the latest attempt at > inheriting stream mappings set up by the bootloader, for e.g. boot splash or > efifb. > > Per Will's request this builds on the work by Jordan and Rob for the Adreno > SMMU

[PATCH v2] iommu/amd: Restore IRTE.RemapEn bit for amd_iommu_activate_guest_mode

2020-09-16 Thread Suravee Suthikulpanit
Commit e52d58d54a32 ("iommu/amd: Use cmpxchg_double() when updating 128-bit IRTE") removed an assumption that modify_irte_ga always set the valid bit, which requires the callers to set the appropriate value for the struct irte_ga.valid bit before calling the function. Similar to the commit

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-09-16 Thread Neil Armstrong
On 16/09/2020 01:51, Robin Murphy wrote: > According to a downstream commit I found in the Khadas vendor kernel, > the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows > how to handle this properly) we should describe it as such. Otherwise > the mismatch leads to all manner of fun

Re: [PATCH 0/3] drm: panfrost: Coherency support

2020-09-16 Thread Neil Armstrong
Hi Robin, On 16/09/2020 01:51, Robin Murphy wrote: > Hi all, > > I polished up my original proof-of-concept a little while back, but now > that I've got my hands on my Juno again I've been able to actually test > it to my satisfaction, so here are proper patches! I tested on the Kkadas VIM3,

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote: > And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe): > the PASID space of a PCI function cannot be shared between host and guest, > so we assign the whole PASID table along with the RID. Since we need the

Re: [PATCH v2] iommu/amd: Restore IRTE.RemapEn bit for amd_iommu_activate_guest_mode

2020-09-16 Thread Maxim Levitsky
On Wed, 2020-09-16 at 11:17 +, Suravee Suthikulpanit wrote: > Commit e52d58d54a32 ("iommu/amd: Use cmpxchg_double() when updating > 128-bit IRTE") removed an assumption that modify_irte_ga always set > the valid bit, which requires the callers to set the appropriate value > for the struct

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

2020-09-16 Thread Jean-Philippe Brucker
On Fri, Aug 28, 2020 at 05:28:22PM +0800, Zenghui Yu wrote: > On 2020/5/20 1:54, Jean-Philippe Brucker wrote: > > @@ -4454,6 +4470,12 @@ static int arm_smmu_device_hw_probe(struct > > arm_smmu_device *smmu) > > smmu->features |= ARM_SMMU_FEAT_E2H; > > } > > + if (reg &

[PATCH 3/3] iommu: amd: Re-purpose Exclusion range registers to support SNP CWWB

2020-09-16 Thread Suravee Suthikulpanit
When the IOMMU SNP support bit is set in the IOMMU Extended Features register, hardware re-purposes the following registers: 1. IOMMU Exclusion Base register (MMIO offset 0020h) to Completion Wait Write-Back (CWWB) Base register 2. IOMMU Exclusion Range Limit (MMIO offset 0028h) to

[PATCH 1/3] iommu: amd: Use 4K page for completion wait write-back semaphore

2020-09-16 Thread Suravee Suthikulpanit
IOMMU SNP support requires the completion wait write-back semaphore to be implemented using a 4K-aligned page, where the page address is to be programmed into the newly introduced MMIO base/range registers. This new scheme uses a per-iommu atomic variable to store the current semaphore value,

[PATCH 0/3] amd : iommu : Initial IOMMU support for SNP

2020-09-16 Thread Suravee Suthikulpanit
Introducing support for AMD Secure Nested Paging (SNP) with IOMMU, which mainly affects the use of IOMMU Exclusion Base and Range Limit registers. Note that these registers are no longer used by Linux IOMMU driver. Patch 2 and 3 are SNP-specific, and discuss detail of the implementation. In order

[PATCH 2/3] iommu: amd: Add support for RMP_PAGE_FAULT and RMP_HW_ERR

2020-09-16 Thread Suravee Suthikulpanit
IOMMU SNP support introduces two new IOMMU events: * RMP Page Fault event * RMP Hardware Error event Hence, add reporting functions for these events. Cc: Brijesh Singh Signed-off-by: Suravee Suthikulpanit --- drivers/iommu/amd/amd_iommu_types.h | 2 + drivers/iommu/amd/iommu.c

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote: > > If user space wants to bind page tables, create the PASID with > > /dev/sva, use ioctls there to setup the page table the way it wants, > > then pass the now configured PASID to a driver that can use it. > > Are we talking

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, September 15, 2020 10:29 PM > > > > > Do they need a device at all? It's not clear to me why RID based > > > IOMMU management fits within vfio's scope, but PASID based does not. > > > > In

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote: > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote: > > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote: > > > > If user space wants to bind page tables, create the PASID with > > > > /dev/sva, use ioctls

Re: [PATCH 6/6] dma-mapping: introduce DMA range map, supplanting dma_pfn_offset

2020-09-16 Thread Mathieu Poirier
On Wed, Sep 16, 2020 at 08:14:59AM +0200, Christoph Hellwig wrote: > From: Jim Quinlan > > 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

Re: [PATCH 0/3] drm: panfrost: Coherency support

2020-09-16 Thread Alyssa Rosenzweig
> So I get a performance regression with the dma-coherent approach, even if it's > clearly the cleaner. That's bizarre -- this should really be the faster of the two. signature.asc Description: PGP signature ___ iommu mailing list

Re: [PATCH 0/3] drm: panfrost: Coherency support

2020-09-16 Thread Rob Herring
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig wrote: > > > So I get a performance regression with the dma-coherent approach, even if > > it's > > clearly the cleaner. > > That's bizarre -- this should really be the faster of the two. Coherency may not be free. CortexA9 had something like

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote: > Hi Jason, > On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe > wrote: > > > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote: > > > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote: > > > > On Tue,

Re: [PATCH v2] iommu/amd: Restore IRTE.RemapEn bit for amd_iommu_activate_guest_mode

2020-09-16 Thread Joao Martins
On 9/16/20 12:17 PM, Suravee Suthikulpanit wrote: > Commit e52d58d54a32 ("iommu/amd: Use cmpxchg_double() when updating > 128-bit IRTE") removed an assumption that modify_irte_ga always set > the valid bit, which requires the callers to set the appropriate value > for the struct irte_ga.valid bit

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jean-Philippe Brucker
On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote: > > And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe): > > the PASID space of a PCI function cannot be shared between host and guest, > >

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Auger Eric
Hi, On 9/16/20 6:32 PM, Jason Gunthorpe wrote: > On Wed, Sep 16, 2020 at 06:20:52PM +0200, Jean-Philippe Brucker wrote: >> On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote: >>> On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote: And this is the only PASID

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jacob Pan (Jun)
Hi Jason, On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe wrote: > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote: > > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote: > > > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote: > > > > > If user

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Raj, Ashok
On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote: > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote: > > > If user space wants to bind page tables, create the PASID with > > > /dev/sva, use ioctls there to setup the page table the way it wants, > > > then pass the

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Gunthorpe
On Wed, Sep 16, 2020 at 06:20:52PM +0200, Jean-Philippe Brucker wrote: > On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote: > > On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote: > > > And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe): > > >

Re: intel_iommu=on breaks resume from suspend on several Thinkpad models

2020-09-16 Thread Jarkko Sakkinen
On Sun, Sep 06, 2020 at 11:38:08PM -0400, Ronan Jouchet wrote: > Hi. This is a follow-up of [BUG] > https://bugzilla.kernel.org/show_bug.cgi?id=197029 , > where Jarkko Sakkinen asks in comment 31 to move discussion here. > > [1.] One line summary of the problem: > > intel_iommu=on breaks resume

Re: [PATCH v9 1/7] docs: IOMMU user API

2020-09-16 Thread Randy Dunlap
On 9/11/20 2:57 PM, Jacob Pan wrote: > IOMMU UAPI is newly introduced to support communications between guest > virtual IOMMU and host IOMMU. There has been lots of discussions on how > it should work with VFIO UAPI and userspace in general. > > This document is intended to clarify the UAPI

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jacob Pan (Jun)
Hi Jason, On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe wrote: > On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote: > > Hi Jason, > > On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe > > wrote: > > > > > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote: > >

[PATCH V2] dma-direct: Fix potential NULL pointer dereference

2020-09-16 Thread Thomas Tai
When booting the kernel v5.9-rc4 on a VM, the kernel would panic when printing a warning message in swiotlb_map(). The dev->dma_mask must not be a NULL pointer when calling the dma mapping layer. A NULL pointer check can potentially avoid the panic. [drm] Initialized virtio_gpu 0.1.0 0 for

Re: [PATCH v5] PCI/ACS: Enable PCI_ACS_TB and disable only when needed for ATS

2020-09-16 Thread Bjorn Helgaas
On Tue, Jul 14, 2020 at 01:15:40PM -0700, Rajat Jain wrote: > The ACS "Translation Blocking" bit blocks the translated addresses from > the devices. We don't expect such traffic from devices unless ATS is > enabled on them. A device sending such traffic without ATS enabled, > indicates malicious

Re: [PATCH v4 4/4] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices

2020-09-16 Thread Bjorn Helgaas
On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote: > When enabling ACS, enable translation blocking for external facing ports > and untrusted devices. > > Signed-off-by: Rajat Jain Applied (slightly modified) to pci/acs for v5.10, thanks! I think the warning is superfluous because

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Jason Wang
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote: Hi Jason, On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe wrote: On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote: Hi Jason, On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe wrote: On Wed, Sep 16, 2020 at 09:33:43AM