On Fri, Jul 08, 2022 at 05:00:59PM +0800, Baolu Lu wrote:
> Do we really need to export this symbol? It is not used beyond the iommu
> core code.
virtio-iommu calls it and can be modular.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://li
On Fri, Jul 08, 2022 at 11:12:45AM +0100, Will Deacon wrote:
> Heads up, but I think this might collide (trivially?) with:
>
> https://lore.kernel.org/r/20220615101044.1972-1-shameerali.kolothum.th...@huawei.com
>
> which Joerg has queued up already. It looks like the cleanup still makes
> sense
Fold the arm_smmu_dev_has_feature arm_smmu_dev_feature_enabled into
the main methods.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 55 ++---
1 file changed, 14 insertions(+), 41 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm
On Thu, Jul 07, 2022 at 04:24:36AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Traditionally swiotlb was not performance critical because it was only
> used for slow devices. But in some setups, like TDX/SEV confidential
> guests, all IO has to go through swiotlb. Currently swiotlb only has a
This method is never actually called.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
include/linux/iommu.h | 4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b
All drivers that implement get_resv_regions just use
generic_put_resv_regions to implement the put side. Remove the
indirections and document the allocations constraints.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/amd/iommu.c | 1 -
drivers/iommu/apple-dart.c
On Thu, Jul 07, 2022 at 10:09:27AM +0200, Greg Kroah-Hartman wrote:
> > Anyone who has real concerns, please scream now.
>
> Sounds like a good plan to me, pull it in and let's see if anyone even
> notices.
Ok, I've added the series to the dma-mapping tree now.
___
Remove the unused iommu_dev_feature_enabled function.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/iommu.c | 13 -
include/linux/iommu.h | 9 -
3 files changed, 23
Hi all,
this removes a bit of dead code and methods from the iommu code and the
cleans up the arm-smmu-v3 driver a little bit based on that.
Changes since v1:
- rebased to the latest iommu/core branch
- don't accidentally change an error code in arm_smmu_dev_enable_feature
- add a kerneldoc co
On Wed, Jul 06, 2022 at 09:50:27PM +0200, Andrea Parri (Microsoft) wrote:
> @@ -305,6 +306,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> ret = page_address(page);
> if (dma_set_decrypted(dev, ret, size))
> goto out_free_pages;
> +#
On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote:
> > Any comments or additional testing? It would be really great to get
> > this off the table.
>
> For the USB bits:
>
> Acked-
On Wed, Jul 06, 2022 at 02:40:44PM +0100, John Garry wrote:
> On 30/06/2022 13:08, John Garry wrote:
>
> Hi Christoph,
>
> Can you please consider picking up this series? A few things to note
> beforehand:
>
> - I changed to only apply the mapping limit to SAS hosts in this version. I
> would nee
On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote:
> Swiotlb_init() is called in the mem_init() of different architects and
> memblock free pages are released to the buddy allocator just after
> calling swiotlb_init() via memblock_free_all().
Yes.
> The mem_init() is called before smp_in
On Fri, Jul 01, 2022 at 01:02:21AM +0800, Tianyu Lan wrote:
> > Can we reorder that initialization? Because I really hate having
> > to have an arch hook in every architecture.
>
> How about using "flags" parameter of swiotlb_init() to pass area number
> or add new parameter for area number?
>
>
On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote:
> The current version does it through a char device, but that requires
> creating a simple_fs and anon_inode for teardown on driver removal, plus
> a bunch of hooks through the driver that exposes it (NVMe, in this case)
> to set this
[note for the newcomers, this is about allowing mmap()ing the PCIe
P2P memory from the generic PCI P2P code through sysfs, and more
importantly how to revoke it on device removal]
On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote:
> We might be able to. I'm not sure. I'll have to fig
On Tue, Jul 05, 2022 at 10:41:52AM -0600, Logan Gunthorpe wrote:
> Using sysfs means we don't need all the messy callbacks from the nvme
> driver, which is a plus. But I'm not sure how we'd get or unmap the
> mapping of a sysfs file or avoid the anonymous inode. Seems with the
> existing PCI resour
On Tue, Jul 05, 2022 at 01:29:59PM -0300, Jason Gunthorpe wrote:
> > Making the entire area given by the device to the p2p allocator available
> > to user space seems sensible to me. That is what the current series does,
> > and what a sysfs interface would do as well.
>
> That makes openning the
On Tue, Jul 05, 2022 at 10:51:02AM -0300, Jason Gunthorpe wrote:
> > In fact I'm not even sure this should be a character device, it seems
> > to fit it way better with the PCI sysfs hierchacy, just like how we
> > map MMIO resources, which these are anyway. And once it is on sysfs
> > we do have
On Wed, Jun 29, 2022 at 02:59:06PM -0300, Jason Gunthorpe wrote:
> I've tried in the past, this is not a good idea. There is no way to
> handle failures when a VMA is dup'd and if you rely on private_data
> you almost certainly have to alloc here.
>
> Then there is the issue of making the locking
On Thu, Jun 30, 2022 at 03:50:10PM -0600, Logan Gunthorpe wrote:
> Oh, it turns out this code has nothing to do with REQ_NOMERGE. It's used
> indirectly in bio_map_user_iov() and __bio_iov_iter_get_pages() when
> adding pages to the bio via page_is_mergeable(). So it's not about
> requests being me
Thanks, this looks good with a minor nit below:
Reviewed-by: Christoph Hellwig
Mathieu, can you pick this up through your tree as that is where the
offending commit was merged through?
> Fixes: e61c451476e6("dma-mapping: Add dma_release_coherent_memory to DMA API")
missing spa
On Mon, Jun 27, 2022 at 11:31:49AM -0400, Tianyu Lan wrote:
> +/**
> + * struct io_tlb_area - IO TLB memory area descriptor
> + *
> + * This is a single area with a single lock.
> + *
> + * @used:The number of used IO TLB block.
> + * @index: The slot index to start searching in this area for
On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> When initialize swiotlb bounce buffer, smp_init() has not been
> called and cpu number can not be got from num_online_cpus().
> Use the number of lapic entry to set swiotlb area number and
> keep swiotlb area numbe
Given how long this is stuck and how big and touching many subsystems,
can we start to make progress on this pice-mail?
I think patches 1-13 look pretty solid, and assuming an review for the
dma-iommu bits these patches could probaby be queued up ASAP.
_
On Wed, Jun 15, 2022 at 10:12:32AM -0600, Logan Gunthorpe wrote:
> A pseudo mount is used to allocate an inode for each PCI device. The
> inode's address_space is used in the file doing the mmap so that all
> VMAs are collected and can be unmapped if the PCI device is unbound.
> After unmapping, th
On Wed, Jun 15, 2022 at 10:12:28AM -0600, Logan Gunthorpe wrote:
> Consecutive zone device pages should not be merged into the same sgl
> or bvec segment with other types of pages or if they belong to different
> pgmaps. Otherwise getting the pgmap of a given segment is not possible
> without scann
I think this is going to have massive conflicts with Al's iov_iter
support..
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
annot be set if FOLL_LONGTERM is set.
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
viewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
t; Reviewed-by: Max Gurtovoy
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
A use cases are restricted to newer root complexes and
> roughly require the extra address space for memory BARs used in the
> transactions.
>
> Signed-off-by: Logan Gunthorpe
> Reviewed-by: Chaitanya Kulkarni
Looks good:
Reviewed-by: Christoph Hellwig
__
Any comments or additional testing? It would be really great to get
this off the table.
On Tue, Jun 14, 2022 at 11:20:37AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> arm is the last platform not using the dma-direct code for directly
> mapped DMA. With the dmaboune removal from
On Wed, Jun 29, 2022 at 09:38:00AM +1200, Michael Schmitz wrote:
> That's one of the 'liberties' I alluded to. The reason I left these in is
> that I'm none too certain what device feature the DMA API uses to decide a
> device isn't cache-coherent.
The DMA API does not look at device features at a
On Wed, Jun 29, 2022 at 11:09:00AM +1200, Michael Schmitz wrote:
> And all SCSI buffers are allocated using kmalloc? No way at all for user
> space to pass unaligned data?
Most that you will see actually comes from the page allocator. But
the block layer has a dma_alignment limit, and when usersp
On Tue, Jun 28, 2022 at 12:33:58PM +0100, John Garry wrote:
> Well Christoph originally offered to take this series via the dma-mapping
> tree.
>
> @Christoph, is that still ok with you? If so, would you rather I send this
> libata patch separately?
The offer still stands, and I don't really car
The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e:
Linux 5.19-rc3 (2022-06-19 15:06:47 -0500)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git
tags/dma-mapping-5.19-2022-06-26
for you to fetch changes up to 3be4562584bba603
On Fri, Jun 24, 2022 at 02:51:39PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The IOMMU mailing list will move from lists.linux-foundation.org to
> lists.linux.dev. The hard switch of the archive will happen on July
> 5th, but add the new list now already so that people start using the
>
On Wed, Jun 22, 2022 at 10:26:01AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The IOMMU mailing list will move from lists.linux-foundation.org to
> lists.linux.dev. The hard switch of the archive will happen on July
> 5th, but add the new list now already so that people start using the
>
On Thu, Jun 23, 2022 at 07:00:58AM +, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to
> dma_set_encrypted():
> out_encrypt_pages:
> if (d
On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
>
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui
see:
commit 4a37f3dd9a8318
On Wed, Jun 22, 2022 at 10:25:40AM -0600, Mathieu Poirier wrote:
> On Sat, Apr 23, 2022 at 07:46:50PM +0200, Christoph Hellwig wrote:
> > Sigh. In theory drivers should never declare coherent memory like
> > this, and there has been some work to fix remoteproc in that regard.
>
On Wed, Jun 22, 2022 at 03:29:52PM +0100, Steven Price wrote:
> The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
> make the swiotlb_init interface more useful") but the declaration was
> left in swiotlb.h. Tidy up by removing the declaration as well.
>
> Signed-off-by: Steven
I'd really like to hear something from the driver maintainers. The
cod change itself looks fine, we just need to make sure it does not
break any driver assumptions.
And I think at least for the PCIe P2P and NTB cases I fear it might
break them. The proper logic for those is in the p2p helpers, b
Thanks,
this looks pretty good to me. A few comments below:
On Fri, Jun 17, 2022 at 10:47:41AM -0400, Tianyu Lan wrote:
> +/**
> + * struct io_tlb_area - IO TLB memory area descriptor
> + *
> + * This is a single area with a single lock.
> + *
> + * @used:The number of used IO TLB block.
> +
Thanks,
I've applied all 4 to the dma-mapping tree for Linux 5.20.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote:
> Put simply, if you want to call dma_map_single() on a buffer, then that
> buffer needs to be allocated with kmalloc() (or technically alloc_pages(),
> but then dma_map_page() would make more sense when dealing with entire
> pages.
-by: Christoph Hellwig
Tested-by: Marc Zyngier
---
arch/arm/mm/dma-mapping.c | 37 +
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e7ccf7c82e025..e68d1d2ac4be0 100644
--- a/arch/arm
From: Robin Murphy
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
Signed-off-by: Christoph Hellwig
Tested-by: Marc Zyngier
---
arch/
-off-by: Christoph Hellwig
Tested-by: Marc Zyngier
---
arch/arm/mm/dma-mapping.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ceb56928d01ec..4055f2dc2859e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch
for non-coherent devices is still
used as is using the arch_dma_alloc/arch_dma_free hooks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
Acked-by: Andre Przywara [highbank]
Tested-by: Marc Zyngier
---
arch/arm/Kconfig | 4 +-
arch/arm/include/asm/dma-mapping.h
Use the helpers as expected by the dma-direct code in the old arm
dma-mapping code to ease a gradual switch to the common DMA code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
Tested-by: Marc Zyngier
---
arch/arm/mm/dma-mapping.c | 24
1 file changed
Only the footbridge platforms provide their own DMA address translation
helpers, so switch to the generic version for all other platforms, and
consolidate the footbridge implementation to remove two levels of
indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
Tested-by
virt_to_dma was only used by the now removed dmabounce code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
Tested-by: Marc Zyngier
---
arch/arm/include/asm/dma-direct.h | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/dma
With the dmabounce removal these aren't used outside of dma-mapping.c,
so mark them static. Move the dma_map_ops declarations down a bit
to avoid lots of forward declarations.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
Tested-by: Marc Zyngier
---
arch/arm/include/as
Remove the now unused dmabounce code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
---
arch/arm/common/Kconfig| 4 -
arch/arm/common/Makefile | 1 -
arch/arm/common/dmabounce.c| 582 -
arch/arm/include/asm/device.h
Walleij
Cc: Russell King
Cc: Christoph Hellwig
Cc: Laurentiu Tudor
Cc: linux-...@vger.kernel.org
Signed-off-by: Arnd Bergmann
Reviewed-by: Greg Kroah-Hartman
Acked-by: Alan Stern
Signed-off-by: Christoph Hellwig
---
arch/arm/common/Kconfig| 2 +-
arch/arm/common/sa.c | 64 ---
Hi all,
arm is the last platform not using the dma-direct code for directly
mapped DMA. With the dmaboune removal from Arnd we can easily switch
arm to always use dma-direct now (it already does for LPAE configs
and nommu). I'd love to merge this series through the dma-mapping tree
as it gives u
On Fri, Jun 10, 2022 at 02:56:08PM -0700, Dongli Zhang wrote:
> Since this patch file has 200+ lines, would you please help clarify what does
> 'this' indicate?
This indicates that any choice of a different swiotlb pools needs to
be hidden inside of Ń•wiotlb. The dma mapping API already provides
s
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote:
> + If you have a modern PCI Express based system, this feature mostly
> just
Overly long line here.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
___
iommu mailin
On Wed, Jun 08, 2022 at 05:55:49PM -0700, Dongli Zhang wrote:
> @@ -109,19 +110,25 @@ int xen_swiotlb_fixup(void *buf, unsigned long nslabs,
> bool high)
> int rc;
> unsigned int order = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT);
> unsigned int i, dma_bits = order + PAGE_SHIFT;
>
On Wed, Jun 08, 2022 at 05:55:53PM -0700, Dongli Zhang wrote:
> +#define slot_addr(start, idx)((start) + \
> + (((unsigned long)idx) << IO_TLB_SHIFT))
Please just convert it to an inline function.
___
iommu mailing lis
On Wed, Jun 08, 2022 at 05:55:52PM -0700, Dongli Zhang wrote:
> /* Unique numbering for virtio devices. */
> @@ -241,6 +243,12 @@ static int virtio_dev_probe(struct device *_d)
> u64 device_features;
> u64 driver_features;
> u64 driver_features_legacy;
> + struct device *pare
This should be handled under the hood without the driver even knowing.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
All this really needs to be hidden under the hood.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Jun 08, 2022 at 05:55:47PM -0700, Dongli Zhang wrote:
> @@ -109,6 +109,7 @@ struct io_tlb_mem {
> } *slots;
> };
> extern struct io_tlb_mem io_tlb_default_mem;
> +extern struct io_tlb_mem io_tlb_high_mem;
Tis should not be exposed.
> +extern bool swiotlb_high_active(void);
And th
59 +0200)
dma-mapping fixes for Linux 5.19
- fix a regressin in setting swiotlb ->force_bounce (me)
- make dma-debug less chatty (Rob Clark)
----
Christoph Hellwig (1):
swiotlb: fix setting ->force_bou
nterface more useful")
Reported-by: Nathan Chancellor
Signed-off-by: Christoph Hellwig
Tested-by: Nathan Chancellor
---
kernel/dma/swiotlb.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index dfa1de89dc944..
On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrot
On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > Can you send me the full dmesg and the content of
> > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
>
> Sure thi
Can you send me the full dmesg and the content of
/sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
Thanks!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Jun 01, 2022 at 09:56:13AM +0200, Lukas Bulwahn wrote:
> +F: arch/x86/kernel/pci-dma.c
I think this file is better left for the x86 maintainers.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/l
On Tue, May 31, 2022 at 03:19:45PM -0700, Rob Clark wrote:
> um, quite.. tbf that was in the context of a WIP igt test for
> shrinker which was trying to cycle thru ~2x RAM size worth of GEM
> buffers on something like 72 threads. So it could just be threads
> that had gotten past the dma_debug_d
ka)
- fix DMA_ATTR_NO_KERNEL_MAPPING on xen/arm (me)
- don't fail on highmem CMA pages in dma_direct_alloc_pages (me)
- cleanup swiotlb initialization and share more code with swiotlb-xen
(me, Stefano Stabellini)
----
Christoph Hellwig
The whole series looks fine to me. I'll happily queue it up in the
dma-mapping tree if the SCSI and ATA maintainers are ok with that.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Thanks,
applied to the dma-mapping for-next branch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
this and
> avoid calling them.
>
> Otherwise asserting dma ownership will fail for VFIO mdev devices as a
> BLOCKING iommu_domain cannot be allocated due to the NULL iommu ops.
Fake iommu groups come back to bite again, part 42..
The patch looks good:
Reviewed-
On Wed, May 18, 2022 at 06:36:59PM +0100, Robin Murphy wrote:
> +config IOMMU_DMA_PCI_SAC_OPT
> + bool "Enable 64-bit legacy PCI optimisation by default"
> + depends on IOMMU_DMA
> + default X86
> + help
> + Enable by default an IOMMU optimisation for 64-bit legacy PCI devices
On Wed, May 18, 2022 at 11:21:16AM -0700, Jacob Pan wrote:
> +ioasid_t iommu_get_pasid_from_domain(struct device *dev, struct iommu_domain
> *domain)
Overly long line here.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfound
On Tue, May 17, 2022 at 01:02:00PM +0100, Robin Murphy wrote:
>> So how to inform the SCSI driver of this caching limit then so that it may
>> limit the SGL length?
>
> Driver-specific mechanism; block-layer-specific mechanism; redefine this
> whole API to something like dma_opt_mapping_size(), a
On Tue, May 17, 2022 at 11:40:52AM +0100, Robin Murphy wrote:
> Indeed, sorry but NAK for this being nonsense. As I've said at least once
> before, if the unnecessary SAC address allocation attempt slows down your
> workload, make it not do that in the first place. If you don't like the
> existi
Thanks,
applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, May 17, 2022 at 10:02:00AM +0100, John Garry wrote:
> BTW, on a separate topic, I noticed that even with this change my ATA
> devices have max_hw_sectors_kb of 32767, as opposed to 128 for SAS devices.
> It seems that libata-scsi - specifically ata_scsi_dev_config() - doesn't
> honour th
On Mon, May 16, 2022 at 09:06:01PM +0800, John Garry wrote:
> For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
> exceeds the IOVA rcache upper limit (meaning that they are not cached),
> performance can be reduced.
>
> Add the IOMMU callback for DMA mapping API dma_max_ma
On Fri, May 13, 2022 at 05:39:48PM +0200, Niklas Schnelle wrote:
> In __iommu_dma_alloc_noncontiguous() the value returned by
> iommu_map_sg_atomic() is checked for being smaller than size. Before
> commit ad8f36e4b6b1 ("iommu: return full error code from
> iommu_map_sg[_atomic]()") this simply che
I don't really understand how 'childs' fit in here. The code also
doesn't seem to be usable without patch 2 and a caller of the
new functions added in patch 2, so it is rather impossible to review.
Also:
1) why is SEV/TDX so different from other cases that need bounce
buffering to treat it
On Mon, May 16, 2022 at 09:57:56AM +0800, Lu Baolu wrote:
> Each IOMMU driver must provide a blocking domain ops. If the hardware
> supports detaching domain from device, setting blocking domain equals
> detaching the existing domain from the deivce. Otherwise, an UNMANAGED
> domain without any map
Looks good,
Reviewed-by: Christoph Hellwig
we really should not keep dead code like this around.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
s series cleanups all includes of intel-iommu.h outside of the Intel
> IOMMU driver and move this header from include/linux to
> drivers/iommu/intel/.
>
> No functional changes intended. Please help to review and suggest.
Thanks, this was long overdue!
The series looks good to me
On Fri, Apr 29, 2022 at 04:15:38PM -0700, Stefano Stabellini wrote:
> Great! Christoph you can go ahead and pick it up in your tree if you are
> up for it.
The patch is in the dma-mapping for-next brancch now:
http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/62cb1ca1654b57589c582efae
b1c05 ("swiotlb: remove swiotlb_init_with_tbl and
swiotlb_init_late_with_tbl")
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 113e1e8aaca37
1 - 100 of 2607 matches
Mail list logo
