Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 2023-09-25 14:29, Jason Gunthorpe wrote: On Mon, Sep 25, 2023 at 02:07:50PM +0100, Robin Murphy wrote: On 2023-09-23 00:33, Jason Gunthorpe wrote: On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote: virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings eit

Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 2023-09-23 00:33, Jason Gunthorpe wrote: On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote: virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings either; it sets it once it's discovered any instance, since apparently it's assuming that all instances must supp

Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 22/09/2023 5:27 pm, Jason Gunthorpe wrote: On Fri, Sep 22, 2023 at 02:13:18PM +0100, Robin Murphy wrote: On 22/09/2023 1:41 pm, Jason Gunthorpe wrote: On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote: They're not strictly equivalent: this check works around a temporary

Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 22/09/2023 1:41 pm, Jason Gunthorpe wrote: On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote: They're not strictly equivalent: this check works around a temporary issue with the IOMMU core, which calls map/unmap before the domain is finalized. Where? The above points to

Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 2023-09-19 09:15, Jean-Philippe Brucker wrote: On Mon, Sep 18, 2023 at 05:37:47PM +0100, Robin Murphy wrote: diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index 17dcd826f5c2..3649586f0e5c 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c

Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

On 2023-09-18 12:51, Niklas Schnelle wrote: Pull out the sync operation from viommu_map_pages() by implementing ops->iotlb_sync_map. This allows the common IOMMU code to map multiple elements of an sg with a single sync (see iommu_map_sg()). Furthermore, it is also a requirement for

Re: [PATCH 2/2] iommu/virtio: Add ops->flush_iotlb_all and enable deferred flush

On 2023-09-04 16:34, Jean-Philippe Brucker wrote: On Fri, Aug 25, 2023 at 05:21:26PM +0200, Niklas Schnelle wrote: Add ops->flush_iotlb_all operation to enable virtio-iommu for the dma-iommu deferred flush scheme. This results inn a significant increase in in performance in exchange for a

Re: [PATCH] iommu: Explicitly include correct DT includes

IW, Acked-by: Robin Murphy I guess you're hoping for Joerg to pick this up? However I wouldn't foresee any major conflicts if you do need to take it through the OF tree. Cheers, Robin. Signed-off-by: Rob Herring --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +- drivers/iommu/ar

Re: [PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()

On 2023-01-18 18:00, Jason Gunthorpe wrote: Change the sg_alloc_table_from_pages() allocation that was hardwired to GFP_KERNEL to use the gfp parameter like the other allocations in this function. Auditing says this is never called from an atomic context, so it is safe as is, but reads wrong.

Re: [PATCH 1/8] iommu: Add a gfp parameter to iommu_map()

On 2023-01-06 16:42, Jason Gunthorpe wrote: The internal mechanisms support this, but instead of exposting the gfp to the caller it wrappers it into iommu_map() and iommu_map_atomic() Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT. FWIW, since we *do* have two variants

Re: The arm smmu driver for Linux does not support debugfs

On 2022-11-15 02:28, leo-...@hotmail.com wrote: Hi, Why doesn't the arm smmu driver for Linux support debugfs ? Because nobody's ever written any debugfs code for it. Are there any historical reasons? Only that so far nobody's needed to. TBH, arm-smmu is actually quite

Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions

On 2022-09-14 18:58, Nicolin Chen wrote: On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote: External email: Use caution opening links or attachments On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote: On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe

Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 2022-09-08 01:43, Jason Gunthorpe wrote: On Wed, Sep 07, 2022 at 08:41:13PM +0100, Robin Murphy wrote: FWIW, we're now very close to being able to validate dev->iommu against where the domain came from in core code, and so short-circuit ->attach_dev entirely if they don't match. I

Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 2022-09-07 18:00, Jason Gunthorpe wrote: On Wed, Sep 07, 2022 at 03:23:09PM +0100, Robin Murphy wrote: On 2022-09-07 14:47, Jason Gunthorpe wrote: On Wed, Sep 07, 2022 at 02:41:54PM +0200, Joerg Roedel wrote: On Mon, Aug 15, 2022 at 11:14:33AM -0700, Nicolin Chen wrote: Provide

Re: [PATCH] iommu/virtio: Fix compile error with viommu_capable()

. Fix that by updating the viommu_capable() signature after the merge. I thought I'd called out somewhere that this was going to be a conflict, but apparently not, sorry about that. Acked-by: Robin Murphy Lemme spin a patch for the outstanding LKP warning on the bus series before that gets

Re: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 2022-09-07 14:47, Jason Gunthorpe wrote: On Wed, Sep 07, 2022 at 02:41:54PM +0200, Joerg Roedel wrote: On Mon, Aug 15, 2022 at 11:14:33AM -0700, Nicolin Chen wrote: Provide a dedicated errno from the IOMMU driver during attach that the reason attached failed is because of domain

Re: [PATCH v3] iommu/virtio: Fix interaction with VFIO

flags. Interpreted in the *correct* context, I do think this is objectively less wrong than before. We can't guarantee that the underlying implementation will respect cacheable mappings, but it is true that we can do everything in our power to ask for them. Reviewed-by: Robin Mu

Re: [PATCH v2] iommu/virtio: Fix interaction with VFIO

On 2022-08-19 11:38, Jean-Philippe Brucker wrote: On Thu, Aug 18, 2022 at 09:10:25PM +0100, Robin Murphy wrote: On 2022-08-18 17:38, Jean-Philippe Brucker wrote: Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") requires IOMMU drivers to

Re: [PATCH v2] iommu/virtio: Fix interaction with VFIO

On 2022-08-18 17:38, Jean-Philippe Brucker wrote: Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") requires IOMMU drivers to advertise IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does not provide to userspace the ability to maintain coherency

Re: [PATCH] iommu/virtio: Advertise IOMMU_CAP_CACHE_COHERENCY

On 2022-07-14 14:00, Jean-Philippe Brucker wrote: On Thu, Jul 14, 2022 at 01:01:37PM +0100, Robin Murphy wrote: On 2022-07-14 12:11, Jean-Philippe Brucker wrote: Fix virtio-iommu interaction with VFIO, as VFIO now requires IOMMU_CAP_CACHE_COHERENCY. virtio-iommu does not support non-cacheable

Re: [PATCH] iommu/virtio: Advertise IOMMU_CAP_CACHE_COHERENCY

On 2022-07-14 12:11, Jean-Philippe Brucker wrote: Fix virtio-iommu interaction with VFIO, as VFIO now requires IOMMU_CAP_CACHE_COHERENCY. virtio-iommu does not support non-cacheable mappings, and always expects to be called with IOMMU_CACHE. Can we know this is actually true though? What if

Re: [PATCH] vdpa: Use device_iommu_capable()

On 2022-06-08 12:48, Robin Murphy wrote: Use the new interface to check the capability for our device specifically. Just checking in case this got lost - vdpa is now the only remaining iommu_capable() user in linux-next, and I'd like to be able to remove the old interface next cycle

Re: [PATCH v4 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 01/07/2022 5:43 pm, Nicolin Chen wrote: On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote: diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c index 2ed3594f384e..072cac5ab5a4 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c +++ b/drivers

Re: [PATCH v4 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 2022-06-30 21:36, Nicolin Chen wrote: Cases like VFIO wish to attach a device to an existing domain that was not allocated specifically from the device. This raises a condition where the IOMMU driver can fail the domain attach because the domain and device are incompatible with each other.

Re: [PATCH v3 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group

On 2022-06-29 20:47, Nicolin Chen wrote: On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote: On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote: It's not used in VFIO context. "return 0" just satisfy the iommu framework to go ahead. and yes, here we only allow the shared

Re: [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers

On 2022-05-27 00:50, Dmitry Osipenko wrote: Hello, This patchset introduces memory shrinker for the VirtIO-GPU DRM driver and adds memory purging and eviction support to VirtIO-GPU driver. The new dma-buf locking convention is introduced here as well. During OOM, the shrinker will release BOs

Re: [PATCH v2 3/5] vfio/iommu_type1: Remove the domain->ops comparison

On 2022-06-24 14:16, Jason Gunthorpe wrote: On Wed, Jun 22, 2022 at 08:54:45AM +0100, Robin Murphy wrote: On 2022-06-16 23:23, Nicolin Chen wrote: On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote: The domain->ops validation was added, as a precaution, for mixed-driver syst

Re: [PATCH v2 3/5] vfio/iommu_type1: Remove the domain->ops comparison

On 2022-06-16 23:23, Nicolin Chen wrote: On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote: The domain->ops validation was added, as a precaution, for mixed-driver systems. However, at this moment only one iommu driver is possible. So remove it. It's true on a physical platform.

Re: [PATCH v2 5/5] vfio/iommu_type1: Simplify group attachment

On 2022-06-17 03:53, Tian, Kevin wrote: From: Nicolin Chen Sent: Friday, June 17, 2022 6:41 AM ... - if (resv_msi) { + if (resv_msi && !domain->msi_cookie) { ret = iommu_get_msi_cookie(domain->domain, resv_msi_base); if (ret && ret != -ENODEV)

[PATCH] vdpa: Use device_iommu_capable()

Use the new interface to check the capability for our device specifically. Signed-off-by: Robin Murphy --- drivers/vhost/vdpa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 935a1d0ddb97..4cfebcc24a03 100644 --- a/drivers

Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain

On 2022-06-06 17:51, Nicolin Chen wrote: Hi Robin, On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote: On 2022-06-06 07:19, Nicolin Chen wrote: The core code should not call an iommu driver op with a struct device parameter unless it knows that the dev_iommu_priv_get

Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain

On 2022-06-06 07:19, Nicolin Chen wrote: The core code should not call an iommu driver op with a struct device parameter unless it knows that the dev_iommu_priv_get() for that struct device was setup by the same driver. Otherwise in a mixed driver system the iommu_priv could be casted to the

Re: [PATCH 1/5] iommu: Replace uses of IOMMU_CAP_CACHE_COHERENCY with dev_is_dma_coherent()

On 2022-04-07 14:59, Jason Gunthorpe wrote: On Thu, Apr 07, 2022 at 07:18:48AM +, Tian, Kevin wrote: From: Jason Gunthorpe Sent: Thursday, April 7, 2022 1:17 AM On Wed, Apr 06, 2022 at 06:10:31PM +0200, Christoph Hellwig wrote: On Wed, Apr 06, 2022 at 01:06:23PM -0300, Jason Gunthorpe

Re: [PATCH 1/5] iommu: Replace uses of IOMMU_CAP_CACHE_COHERENCY with dev_is_dma_coherent()

On 2022-04-06 15:14, Jason Gunthorpe wrote: On Wed, Apr 06, 2022 at 03:51:50PM +0200, Christoph Hellwig wrote: On Wed, Apr 06, 2022 at 09:07:30AM -0300, Jason Gunthorpe wrote: Didn't see it I'll move dev_is_dma_coherent to device.h along with device_iommu_mapped() and others then No. It it

Re: [PATCH 1/5] iommu: Replace uses of IOMMU_CAP_CACHE_COHERENCY with dev_is_dma_coherent()

On 2022-04-05 17:16, Jason Gunthorpe wrote: vdpa and usnic are trying to test if IOMMU_CACHE is supported. The correct way to do this is via dev_is_dma_coherent() Not necessarily... Disregarding the complete disaster of PCIe No Snoop on Arm-Based systems, there's the more interesting

Re: [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64

On 2022-03-23 10:11, Gerd Hoffmann wrote: On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote: On 2022-03-23 07:15, Christian K�nig wrote: Am 22.03.22 um 10:34 schrieb Cong Liu: qxl use ioremap to map ram_header and rom, in the arm64 implementation, the device is mapped

Re: [PATCH v1 1/2] drm/qxl: replace ioremap by ioremap_cache on arm64

On 2022-03-23 07:15, Christian König wrote: Am 22.03.22 um 10:34 schrieb Cong Liu: qxl use ioremap to map ram_header and rom, in the arm64 implementation, the device is mapped as DEVICE_nGnRE, it can not support unaligned access. Well that some ARM boards doesn't allow unaligned access to

Re: [PATCH v2 4/8] drm/virtio: Improve DMA API usage for shmem BOs

On 2022-03-14 22:42, Dmitry Osipenko wrote: DRM API requires the DRM's driver to be backed with the device that can be used for generic DMA operations. The VirtIO-GPU device can't perform DMA operations if it uses PCI transport because PCI device driver creates a virtual VirtIO-GPU device that

Re: [PATCH v2] iommu/iova: Separate out rcache init

Make "fast" users call a separate rcache init explicitly, which includes error checking. Reviewed-by: Robin Murphy Signed-off-by: John Garry --- Differences to v1: - Drop stubs for iova_domain_init_rcaches() and iova_domain_free_rcaches() - Use put_iova_domain() in vdpa code diff --git

Re: [PATCH] iommu/iova: Separate out rcache init

On 2022-01-28 11:32, John Garry wrote: On 26/01/2022 17:00, Robin Murphy wrote: As above, I vote for just forward-declaring the free routine in iova.c and keeping it entirely private. BTW, speaking of forward declarations, it's possible to remove all the forward declarations in iova.c now

Re: [PATCH] iommu/iova: Separate out rcache init

On 2022-01-26 13:55, John Garry wrote: Currently the rcache structures are allocated for all IOVA domains, even if they do not use "fast" alloc+free interface. This is wasteful of memory. In addition, fails in init_iova_rcaches() are not handled safely, which is less than ideal. Make "fast"

Re: [PATCH 4/5] iommu: Separate IOVA rcache memories from iova_domain structure

Hi John, On 2021-12-20 08:49, John Garry wrote: On 24/09/2021 11:01, John Garry wrote: Only dma-iommu.c and vdpa actually use the "fast" mode of IOVA alloc and free. As such, it's wasteful that all other IOVA domains hold the rcache memories. In addition, the current IOVA domain init

Re: [PATCH v2] iova: Move fast alloc size roundup into alloc_iova_fast()

than one caller in the first place, but hey. Acked-by: Robin Murphy Signed-off-by: John Garry Acked-by: Will Deacon Reviewed-by: Xie Yongji Acked-by: Jason Wang Acked-by: Michael S. Tsirkin --- Differences to v1: - Separate out from original series which conflicts with Robin's IOVA FQ work

Re: [PATCH 0/5] iommu: Some IOVA code reorganisation

On 2021-11-16 14:21, John Garry wrote: On 04/10/2021 12:44, Will Deacon wrote: On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote: The IOVA domain structure is a bit overloaded, holding: - IOVA tree management - FQ control - IOVA rcache memories Indeed only a couple of IOVA users use

Re: [PATCH 0/5] iommu: Some IOVA code reorganisation

On 2021-10-04 12:44, Will Deacon wrote: On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote: The IOVA domain structure is a bit overloaded, holding: - IOVA tree management - FQ control - IOVA rcache memories Indeed only a couple of IOVA users use the rcache, and only dma-iommu.c uses

Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()

On 2021-08-04 06:02, Yongji Xie wrote: On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy wrote: On 2021-08-03 09:54, Yongji Xie wrote: On Tue, Aug 3, 2021 at 3:41 PM Jason Wang wrote: 在 2021/7/29 下午3:34, Xie Yongji 写道: Export alloc_iova_fast() and free_iova_fast() so that some modules can use

Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()

On 2021-08-03 09:54, Yongji Xie wrote: On Tue, Aug 3, 2021 at 3:41 PM Jason Wang wrote: 在 2021/7/29 下午3:34, Xie Yongji 写道: Export alloc_iova_fast() and free_iova_fast() so that some modules can use it to improve iova allocation efficiency. It's better to explain why alloc_iova() is not

Re: [RFC v1 3/8] intel/vt-d: make DMAR table parsing code more flexible

On 2021-07-09 12:43, Wei Liu wrote: Microsoft Hypervisor provides a set of hypercalls to manage device domains. The root kernel should parse the DMAR so that it can program the IOMMU (with hypercalls) correctly. The DMAR code was designed to work with Intel IOMMU only. Add two more parameters

Re: [RFC v1 6/8] mshv: command line option to skip devices in PV-IOMMU

On 2021-07-09 12:43, Wei Liu wrote: Some devices may have been claimed by the hypervisor already. One such example is a user can assign a NIC for debugging purpose. Ideally Linux should be able to tell retrieve that information, but there is no way to do that yet. And designing that new

Re: [PATCH v5 2/5] ACPI: Move IOMMU setup code out of IORT

the acpi_iommu_fwspec_init() helper. Reviewed-by: Robin Murphy Signed-off-by: Jean-Philippe Brucker --- include/acpi/acpi_bus.h | 3 ++ include/linux/acpi_iort.h | 8 ++--- drivers/acpi/arm64/iort.c | 74 +-- drivers/acpi/scan.c | 73

Re: [PATCH v5 1/5] ACPI: arm64: Move DMA setup operations out of IORT

On 2021-06-18 16:20, Jean-Philippe Brucker wrote: Extract generic DMA setup code out of IORT, so it can be reused by VIOT. Keep it in drivers/acpi/arm64 for now, since it could break x86 platforms that haven't run this code so far, if they have invalid tables. Reviewed-by: Robin Murphy

Re: [PATCH v5 4/5] iommu/dma: Pass address limit rather than size to iommu_setup_dma_ops()

dev->dma_range_map on Arm. But removing them on Arm isn't completely straightforward so is left for future work. As an intermediate step, simplify the x86 callers by passing dummy limits. Reviewed-by: Robin Murphy Signed-off-by: Jean-Philippe Brucker --- include/linux/dma-iommu.h | 4 ++--

Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()

On 2021-06-18 11:50, Jean-Philippe Brucker wrote: On Wed, Jun 16, 2021 at 06:02:39PM +0100, Robin Murphy wrote: diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index c62e19bed302..175f8eaeb5b3 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1322,7

Re: [PATCH v4 2/6] ACPI: Move IOMMU setup code out of IORT

On 2021-06-18 08:41, Jean-Philippe Brucker wrote: Hi Eric, On Wed, Jun 16, 2021 at 11:35:13AM +0200, Eric Auger wrote: -const struct iommu_ops *iort_iommu_configure_id(struct device *dev, - const u32 *id_in) +int iort_iommu_configure_id(struct

Re: [PATCH v4 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()

On 2021-06-10 08:51, Jean-Philippe Brucker wrote: dma-iommu uses the address bounds described in domain->geometry during IOVA allocation. The address size parameters of iommu_setup_dma_ops() are useful for describing additional limits set by the platform firmware, but aren't needed for drivers

Re: [PATCH v1 5/8] dma: Use size for swiotlb boundary checks

On 2021-06-03 01:41, Andi Kleen wrote: swiotlb currently only uses the start address of a DMA to check if something is in the swiotlb or not. But with virtio and untrusted hosts the host could give some DMA mapping that crosses the swiotlb boundaries, potentially leaking or corrupting data. Add

Re: [PATCH v1 6/8] dma: Add return value to dma_unmap_page

Hi Andi, On 2021-06-03 01:41, Andi Kleen wrote: In some situations when we know swiotlb is forced and we have to deal with untrusted hosts, it's useful to know if a mapping was in the swiotlb or not. This allows us to abort any IO operation that would access memory outside the swiotlb.

Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-16 15:38, Christoph Hellwig wrote: [...] diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index f1e38526d5bd40..996dfdf9d375dd 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++

Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-31 16:32, Will Deacon wrote: On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote: On 2021-03-31 12:49, Will Deacon wrote: On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote: On 2021-03-30 14:58, Will Deacon wrote: On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin

Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-31 12:49, Will Deacon wrote: On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote: On 2021-03-30 14:58, Will Deacon wrote: On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote: On 2021-03-30 14:11, Will Deacon wrote: On Tue, Mar 16, 2021 at 04:38:22PM +0100

Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-30 14:58, Will Deacon wrote: On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote: On 2021-03-30 14:11, Will Deacon wrote: On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote: From: Robin Murphy Instead make the global iommu_dma_strict paramete in iommu.c

Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-30 14:11, Will Deacon wrote: On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote: From: Robin Murphy Instead make the global iommu_dma_strict paramete in iommu.c canonical by exporting helpers to get and set it and use those directly in the drivers. This make sure

Re: [PATCH 2/3] ACPI: Add driver for the VIOT table

On 2021-03-16 19:16, Jean-Philippe Brucker wrote: The ACPI Virtual I/O Translation Table describes topology of para-virtual platforms. For now it describes the relation between virtio-iommu and the endpoints it manages. Supporting that requires three steps: (1) acpi_viot_init(): parse the VIOT

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

On 2021-03-16 19:16, Jean-Philippe Brucker wrote: With the VIOT support in place, x86 platforms can now use the virtio-iommu. The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it themselves. Actually, now that both AMD and Intel are converted over, maybe it's finally time

Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-15 08:33, Christoph Hellwig wrote: On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote: Let me know what you think of the version here: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup I'll happily switch the patch to you as the author

Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-11 08:26, Christoph Hellwig wrote: On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote: Actually... Just mirroring the iommu_dma_strict value into struct iommu_domain should solve all of that with very little boilerplate code. Yes, my initial thought was to directly

Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-10 09:25, Christoph Hellwig wrote: On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote: On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote: On 2021-03-01 08:42, Christoph Hellwig wrote: Use explicit methods for setting and querying the information instead

Re: [PATCH 16/17] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG

On 2021-03-01 08:42, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig Moreso than the previous patch, where the feature is at least relatively generic (note that there's a bunch of in-flight development around DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to

Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

On 2021-03-01 08:42, Christoph Hellwig wrote: Use explicit methods for setting and querying the information instead. Now that everyone's using iommu-dma, is there any point in bouncing this through the drivers at all? Seems like it would make more sense for the x86 drivers to reflect their

Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

Hi Tom, On 2019-12-21 15:03, Tom Murphy wrote: This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here:

Re: [PATCH V2 1/2] Add new flush_iotlb_range and handle freelists when using iommu_unmap_fast

On 2020-08-18 07:04, Tom Murphy wrote: Add a flush_iotlb_range to allow flushing of an iova range instead of a full flush in the dma-iommu path. Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This patch is useful

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

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: [RFC PATCH 17/34] iommu/arm-smmu: Store device instead of group in arm_smmu_s2cr

On 2020-04-08 3:37 pm, Joerg Roedel wrote: Hi Robin, thanks for looking into this. On Wed, Apr 08, 2020 at 01:09:40PM +0100, Robin Murphy wrote: For a hot-pluggable bus where logical devices may share Stream IDs (like fsl-mc), this could happen: create device A iommu_probe_device

Re: [RFC PATCH 17/34] iommu/arm-smmu: Store device instead of group in arm_smmu_s2cr

On 2020-04-07 7:37 pm, Joerg Roedel wrote: From: Joerg Roedel This is required to convert the arm-smmu driver to the probe/release_device() interface. Signed-off-by: Joerg Roedel --- drivers/iommu/arm-smmu.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

Re: [RFC PATCH v2] iommu/virtio: Use page size bitmap supported by endpoint

On 2020-04-01 12:38 pm, Bharat Bhushan wrote: Different endpoint can support different page size, probe endpoint if it supports specific page size otherwise use global page sizes. Signed-off-by: Bharat Bhushan --- drivers/iommu/virtio-iommu.c | 33 +++

Re: [PATCH v2 3/3] iommu/virtio: Reject IOMMU page granule larger than PAGE_SIZE

different page masks for each endpoint. Reviewed-by: Robin Murphy Reported-by: Bharat Bhushan Signed-off-by: Jean-Philippe Brucker --- v1->v2: Move to vdomain_finalise(), improve commit message --- drivers/iommu/virtio-iommu.c | 14 -- 1 file changed, 12 insertions(+), 2 deleti

Re: [PATCH v2 2/3] iommu/virtio: Fix freeing of incomplete domains

. Only initialise the vdomain->viommu pointer, which denotes a finalised domain, at the end of a successful viommu_domain_finalise(). Reviewed-by: Robin Murphy Fixes: edcd69ab9a32 ("iommu: Add virtio-iommu driver") Reported-by: Eric Auger Signed-off-by: Jean-Philippe Brucker

Re: [PATCH] iommu/virtio: Reject IOMMU page granule larger than PAGE_SIZE

On 2020-03-18 4:14 pm, Auger Eric wrote: Hi, On 3/18/20 1:00 PM, Robin Murphy wrote: On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote: We don't currently support IOMMUs with a page granule larger than the system page size. The IOVA allocator has a BUG_ON() in this case, and VFIO has

Re: [PATCH] iommu/virtio: Reject IOMMU page granule larger than PAGE_SIZE

On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote: We don't currently support IOMMUs with a page granule larger than the system page size. The IOVA allocator has a BUG_ON() in this case, and VFIO has a WARN_ON(). It might be possible to remove these obstacles if necessary. If the host uses

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote: On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote: On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote: On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote: On 14/02/2020 4:04 pm, Jean-Philippe

Re: [PATCH 2/3] PCI: Add DMA configuration for virtual platforms

On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: Hardware platforms usually describe the IOMMU topology using either device-tree pointers or vendor-specific ACPI tables. For virtual platforms that don't provide a device-tree, the virtio-iommu device contains a description of the endpoints it

Re: [PATCH 3/3] iommu/virtio: Enable x86 support

On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: With the built-in topology description in place, x86 platforms can now use the virtio-iommu. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

On 2019-12-23 10:37 am, Jani Nikula wrote: On Sat, 21 Dec 2019, Tom Murphy wrote: This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You

Re: [PATCH 1/2] dma-mapping: Add dma_addr_is_phys_addr()

() is introduced. cc: Benjamin Herrenschmidt cc: David Gibson cc: Michael Ellerman cc: Paul Mackerras cc: Michael Roth cc: Alexey Kardashevskiy cc: Paul Burton cc: Robin Murphy cc: Bartlomiej Zolnierkiewicz cc: Marek Szyprowski cc: Christoph Hellwig Suggested-by: Michael S. Tsirkin Signed-off-by: Ram

Re: [PATCH V5 4/5] iommu/dma-iommu: Use the dev->coherent_dma_mask

wed-by: Robin Murphy Signed-off-by: Tom Murphy --- drivers/iommu/dma-iommu.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 906b7fa14d3c..b9a3ab02434b 100644 --- a/drivers/iommu/dma-iommu.c ++

Re: [PATCH V5 3/5] iommu/dma-iommu: Handle deferred devices

On 15/08/2019 12:09, Tom Murphy wrote: Handle devices which defer their attach to the iommu in the dma-iommu api Other than nitpicking the name (I'd lean towards something like iommu_dma_deferred_attach), Reviewed-by: Robin Murphy Signed-off-by: Tom Murphy --- drivers/iommu/dma

Re: [PATCH V5 2/5] iommu: Add gfp parameter to iommu_ops::map

which uses the dma-iommu api uses gfp_atomic in it's iommu_ops::map function. But doing this wastes the memory allocators atomic pools. Looks reasonable to me - once we get the merges sorted out I'll take a look at propagating the flags through to io-pgtable for the SMMU drivers and friends. Reviewed

Re: [PATCH 2/2] virtio/virtio_ring: Fix the dma_max_mapping_size call

On 22/07/2019 15:55, Eric Auger wrote: Do not call dma_max_mapping_size for devices that have no DMA mask set, otherwise we can hit a NULL pointer dereference. This occurs when a virtio-blk-pci device is protected with a virtual IOMMU. Fixes: e6d6dd6c875e ("virtio: Introduce

Re: [PATCH 0/3] Fix virtio-blk issue with SWIOTLB

On 14/01/2019 18:20, Michael S. Tsirkin wrote: On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote: On 2019/1/14 下午5:50, Christoph Hellwig wrote: On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote: On 2019/1/11 下午5:15, Joerg Roedel wrote: On Fri, Jan 11, 2019 at 11:29:31AM

Re: [virtio-dev] Re: [PATCH v5 5/7] iommu: Add virtio-iommu driver

On 2018-12-12 3:27 pm, Auger Eric wrote: Hi, On 12/12/18 3:56 PM, Michael S. Tsirkin wrote: On Fri, Dec 07, 2018 at 06:52:31PM +, Jean-Philippe Brucker wrote: Sorry for the delay, I wanted to do a little more performance analysis before continuing. On 27/11/2018 18:10, Michael S. Tsirkin

Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu

On 17/10/18 16:14, Michael S. Tsirkin wrote: On Mon, Oct 15, 2018 at 08:46:41PM +0100, Jean-philippe Brucker wrote: [Replying with my personal address because we're having SMTP issues] On 15/10/2018 11:52, Michael S. Tsirkin wrote: On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas

Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu

On 12/10/18 20:41, Bjorn Helgaas wrote: s/iommu/IOMMU/ in subject On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote: Using the iommu-map binding, endpoints in a given PCI domain can be managed by different IOMMUs. Some virtual machines may allow a subset of endpoints to

Re: [PATCH v2 1/5] dt-bindings: virtio: Specify #iommu-cells value for a virtio-iommu

On 27/06/18 18:46, Rob Herring wrote: On Tue, Jun 26, 2018 at 11:59 AM Jean-Philippe Brucker wrote: On 25/06/18 20:27, Rob Herring wrote: On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote: A virtio-mmio node may represent a virtio-iommu device. This is discovered by the

Re: [PATCH 2/4] iommu/virtio: Add probe request

On 14/02/18 14:53, Jean-Philippe Brucker wrote: When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

On 14/02/18 14:53, Jean-Philippe Brucker wrote: The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

On 21/03/18 13:14, Jean-Philippe Brucker wrote: On 21/03/18 06:43, Tian, Kevin wrote: [...] + +#include + +#define MSI_IOVA_BASE 0x800 +#define MSI_IOVA_LENGTH0x10 this is ARM specific, and according to virtio-iommu spec isn't it better probed

Re: [PATCH 4/4] vfio: Allow type-1 IOMMU instantiation with a virtio-iommu

On 14/02/18 15:26, Alex Williamson wrote: On Wed, 14 Feb 2018 14:53:40 + Jean-Philippe Brucker wrote: When enabling both VFIO and VIRTIO_IOMMU modules, automatically select VFIO_IOMMU_TYPE1 as well. Signed-off-by: Jean-Philippe Brucker

[PATCH v2 1/2] virtio: Make ARM SMMU workaround more specific

A API for ARM-based systems with legacy devices") Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/virtio/virtio_ring.c | 30 -- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/vir

[PATCH v2 2/2] virtio: Document DMA coherency

mishaps. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- Documentation/devicetree/bindings/virtio/mmio.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt

  1   2   >