[GIT PULL] dma-mapping updates for Linux 6.6

[GIT PULL] dma-mapping updates for Linux 6.6

[Christoph Hellwig]

The following changes since commit 5d0c230f1de8c7515b6567d9afba1f196fb4e2f4:

  Linux 6.5-rc4 (2023-07-30 13:23:47 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-6.6-2023-08-29

for you to fetch changes up to d069ed288ac74c24e2b1c294aa9445c80ed6c518:

  swiotlb: optimize get_max_slots() (2023-08-08 10:29:21 -0700)

----------------------------------------------------------------
dma-maping updates for Linux 6.6

 - allow dynamic sizing of the swiotlb buffer, to cater for secure
   virtualization workloads that require all I/O to be bounce buffered
   (Petr Tesarik)
 - move a declaration to a header (Arnd Bergmann)
 - check for memory region overlap in dma-contiguous (Binglei Wang)
 - remove the somewhat dangerous runtime swiotlb-xen enablement and
   unexport is_swiotlb_active (Christoph Hellwig, Juergen Gross)
 - per-node CMA improvements (Yajun Deng)

----------------------------------------------------------------
Arnd Bergmann (1):
      dma-mapping: move arch_dma_set_mask() declaration to header

Binglei Wang (1):
      dma-contiguous: check for memory region overlap

Christoph Hellwig (2):
      x86: always initialize xen-swiotlb when xen-pcifront is enabling
      swiotlb: unexport is_swiotlb_active

Juergen Gross (1):
      xen/pci: add flag for PCI passthrough being possible

Petr Tesarik (11):
      swiotlb: bail out of swiotlb_init_late() if swiotlb is already allocated
      swiotlb: make io_tlb_default_mem local to swiotlb.c
      swiotlb: add documentation and rename swiotlb_do_find_slots()
      swiotlb: separate memory pool data from other allocator data
      swiotlb: add a flag whether SWIOTLB is allowed to grow
      swiotlb: if swiotlb is full, fall back to a transient memory pool
      swiotlb: determine potential physical address limit
      swiotlb: allocate a new memory pool when existing pools are full
      swiotlb: search the software IO TLB only if the device makes use of it
      swiotlb: move slot allocation explanation comment where it belongs
      swiotlb: optimize get_max_slots()

Yajun Deng (2):
      dma-contiguous: support per-numa CMA for all architectures
      dma-contiguous: support numa CMA for specified node

 Documentation/admin-guide/kernel-parameters.txt |  13 +-
 arch/arm/xen/mm.c                               |  10 +-
 arch/arm64/mm/init.c                            |   2 -
 arch/mips/pci/pci-octeon.c                      |   2 +-
 arch/powerpc/kernel/dma-mask.c                  |   1 +
 arch/x86/include/asm/xen/swiotlb-xen.h          |   6 -
 arch/x86/kernel/pci-dma.c                       |  29 +-
 arch/x86/xen/setup.c                            |   6 +
 drivers/base/core.c                             |   4 +-
 drivers/pci/xen-pcifront.c                      |   6 -
 drivers/xen/swiotlb-xen.c                       |   2 +-
 include/linux/device.h                          |  10 +-
 include/linux/dma-map-ops.h                     |  12 +-
 include/linux/dma-mapping.h                     |   2 +
 include/linux/swiotlb.h                         | 131 ++++-
 include/xen/xen.h                               |   6 +
 kernel/dma/Kconfig                              |  26 +-
 kernel/dma/contiguous.c                         | 108 +++-
 kernel/dma/direct.c                             |   2 +-
 kernel/dma/mapping.c                            |   6 -
 kernel/dma/swiotlb.c                            | 698 +++++++++++++++++++++---
 mm/cma.c                                        |  10 +-
 mm/slab_common.c                                |   5 +-
 23 files changed, 910 insertions(+), 187 deletions(-)

Re: [GIT PULL] dma-mapping updates for Linux 6.6

[Linus Torvalds]

On Tue, 29 Aug 2023 at 08:23, Christoph Hellwig <hch@infradead.org> wrote:=
>
> Yajun Deng (2):
>       dma-contiguous: support per-numa CMA for all architectures

What?

This commit seems entirely bogus and is actively misleading.

It claims to enable support for per-numa CMA for all architectures.

It does no such thing.

All it does is to change the default value for a config option. It was
perfectly available before, now it is - incorrectly - made 'default y'
in case the config supports NUME at all.

There seems to be no real reason to change the default value of this
config option. The commit message most definitely doesn't argue for
it, since it talks about something entirely different than what the
code changes does.

I have taken this, but I protest these kinds of nonsensical changes.
That commit is actively misleading and confused, and I think the
default value for that config option should just be 'n' on all
architectures.

Why is this option so important that it should be enabled just because
some minimal NUMA support might be enabled?

Please don't add these kinds of hidden "default y" by making them
default on some much more common option instead.

                Linus

Re: [GIT PULL] dma-mapping updates for Linux 6.6

[Christoph Hellwig]

On Tue, Aug 29, 2023 at 08:54:43PM -0700, Linus Torvalds wrote:
> > Yajun Deng (2):
> >       dma-contiguous: support per-numa CMA for all architectures
> 
> What?
> 
> This commit seems entirely bogus and is actively misleading.
> 
> It claims to enable support for per-numa CMA for all architectures.
> 
> It does no such thing.

It actually does..

> All it does is to change the default value for a config option. It was
> perfectly available before, now it is - incorrectly - made 'default y'
> in case the config supports NUME at all.

It also changes the default, and maybe that shouldn't have been,
but that's not the meat of the change.  The big part of the change
is that the logic to actually reserve the per-node CMA area is now
called from common code instead of arm64 code.  Before you could have
enable the option, but it wouldn't have worked at all.

> 
> There seems to be no real reason to change the default value of this
> config option. The commit message most definitely doesn't argue for
> it, since it talks about something entirely different than what the
> code changes does.
> 
> I have taken this, but I protest these kinds of nonsensical changes.
> That commit is actively misleading and confused, and I think the
> default value for that config option should just be 'n' on all
> architectures.
> 
> Why is this option so important that it should be enabled just because
> some minimal NUMA support might be enabled?
> 
> Please don't add these kinds of hidden "default y" by making them
> default on some much more common option instead.

I think everyone including the maintainer was confused when the initial
arm64 only version was merged by adding the default, it should have
been a depends to start with.  So we'll change this to a depends in a
follow up.

Re: [GIT PULL] dma-mapping updates for Linux 6.6

[Linus Torvalds]

On Tue, 29 Aug 2023 at 23:33, Christoph Hellwig <hch@infradead.org> wrote:
>
> It actually does..

Ahh, bah, mea culpa. That's what I get for having mindlessly looked at
the config part (which was, in my defense, about 90% of it), and
missed the one-liner that actually moved the call from the arm64 init
to the dma init.

But yes, please do look out for making things 'default y' - even if
that 'y' is then a bit indirect.

          Linus

Re: [GIT PULL] dma-mapping updates for Linux 6.6

[pr-tracker-bot]

The pull request you sent on Tue, 29 Aug 2023 17:22:57 +0200:

> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-6.6-2023-08-29

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6c1b980a7e79e55e951b4b2c47eefebc75071209

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html