Pull dma-mapping updates from Marek Szyprowski:

 - swiotlb:
     - new configuration option for the default pool size
       (Jagadeesh Pagadala)
     - reduce overhead for high watermark tracking (chenhuguanshen)

 - minor code cleanups and improvements (Vova Sharaienko, Honglei Huang
   and Marek Szyprowski)

 - add proper tracking of the shared DMA state through direct, pool and
   swiotlb paths (Aneesh Kumar K.V)

   This is important for confidential-computing

* tag 'dma-mapping-7.3-2026-08-24' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma/swiotlb: decouple high watermark tracking from CONFIG_DEBUG_FS
  MAINTAINERS: update tree for DMA MAPPING HELPERS
  dma/swiotlb: introduce Kconfig option for compile-time default pool size
  dma-direct: Improve readability of the dma_direct_map_sg() for P2PDMA case
  iommu/dma: simplify dma_iova_destroy() and drop the free_iova helper
  dma-coherent: use KiB in DMA allocation logs
  dma-coherent: fix spacing coding style issue

* tag 'dma-mapping-7.3-2026-08-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: (23 commits)
  swiotlb: remove unused SWIOTLB_FORCE flag
  dma: swiotlb: handle set_memory_decrypted() failures
  dma: swiotlb: free dynamic pools from process context
  dma-direct: rename ret to cpu_addr in alloc helpers
  dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED
  dma-direct: set decrypted flag for remapped DMA allocations
  dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
  dma-direct: Move dma_direct_map_phys() to dma/direct.c
  dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
  dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED
  dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
  dma: swiotlb: pass mapping attributes by reference
  dma-pool: track decrypted atomic pools and select them via attrs
  dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths
  dma-mapping: Add internal shared allocation attribute
  coco: arm64: s390: powerpc: Mark secure guests with CC_ATTR_GUEST_MEM_ENCRYPT
  dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages
  s390: Expose protected virtualization through cc_platform_has()
  swiotlb: Preserve allocation virtual address for dynamic pools
  dma: free atomic pool pages by physical address
  ...

xs_init() registers xs_reboot_nb before initializing XenStore
communications and starting xenwatch. If either operation fails, the
notifier remains registered and a later initialization attempt can hit a
duplicate registration.

Check the notifier registration result and unregister it on every
subsequent failure path.

Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260807032326.940377-1-dbgh9129@gmail.com>

CONFIG_XEN_AUTO_XLATE is referenced only in code built with CONFIG_XEN
enabled. As it is enabled for all architectures supporting Xen, it can
be just dropped.

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260805082137.1214967-4-jgross@suse.com>

On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.

In Xen specific x86 code it can be just dropped, in non-Xen specific
x86 code it can be replaced with CONFIG_XEN.

In architecture independent code it is used only where CONFIG_XEN is
defined, so it can be replaced with CONFIG_X86 there.

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260805082137.1214967-3-jgross@suse.com>

The handling of extra memory regions done in balloon_add_regions() is not
correct for PV guests, since the initial target is set to reflect the real
memory the system has, not what's described on the memory map, which can be
higher if memory != maxmem.

Introduce separate logic for addition vs subtraction in
balloon_add_regions() and handle extra regions correctly by adding them to
the total amount of pages, instead of subtracting from the current and
target pages amounts.

In the common case PV domU/dom0 and PVH dom0 will use the addition path,
since the initial target reflects the real assigned memory.  HVM and PVH
domUs use the subtraction path, since the target is set based on the amount
of memory reported in the memory map, without accounting for released
regions.

Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0")
Fixes: 0949c646d646 ("Partial revert "x86/xen: fix balloon target initialization for PVH dom0"")
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Tested-by: Matthias Goergens <matthias.goergens@gmail.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260805094008.95778-1-roger@xenproject.org>

When device just got initialized (for example on module load), the
otherend_id field is initialized only after
xenbus_read_otherend_details() gets called. If xenstore watch triggers
xenbus_dev_changed() before that, it might consider still zeroed
otherend_id field (not matching actual xenstore content) as a sign of
device state reset. It can happen because xenstore watch are handled in
another thread (xenwatch), which can run in parallel to the initial
device probe running at module load. In that case, it would call
device_unregister(), which would deadlock against device probe from
module init.

Fix this by considering dev->otherend_id change only after dev->otherend
is set (which happen after otherend_id is initialized).

Fixes: e2dcf9065536 "xen/xenbus: better handle backend crash"
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260803030822.4104093-2-marmarek@invisiblethingslab.com>

Ease diagnosing what actually changed.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>

The use in gnttab_map() is latently buggy, as "frames" there is
xen_pfn_t *, not unsigned long *. Adjust the correct use in
gnttab_map_frames_v2() as well, just to avoid the problematic pattern of
sizeof(<type>).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>

Message-ID: <0ddff6c4-7ec7-41a9-9417-687ca16aaafd@suse.com>

The driver sets acpi_device_name() and acpi_device_class() which are
never read afterward, so make it stop doing that and drop the symbols
defined specifically for this purpose.

No intentional functional impact.

This will facilitate the removal of device_name and device_class from
struct acpi_device_pnp in the future.

Signed-off-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <2384190.iZASKD2KPV@rafael.j.wysocki>

Teach dma_capable() about DMA_ATTR_CC_SHARED so the capability
check can reject encrypted DMA addresses for devices that require
unencrypted/shared DMA.

Also propagate DMA_ATTR_CC_SHARED in swiotlb_map() when the selected
SWIOTLB pool is decrypted so the capability check sees the correct DMA
address attribute.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Jiri Pirko <jiri@nvidia.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Link: https://lore.kernel.org/r/20260717180442.110954-16-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>