<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/xen, branch v5.19-rc7</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices</title>
<updated>2022-06-06T14:07:30+00:00</updated>
<author>
<name>Oleksandr Tyshchenko</name>
<email>oleksandr_tyshchenko@epam.com</email>
</author>
<published>2022-06-02T19:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fea981610c25173e6e5d63ccd4fce49739663ab0'/>
<id>fea981610c25173e6e5d63ccd4fce49739663ab0</id>
<content type='text'>
By assigning xen-grant DMA ops we will restrict memory access for
passed device using Xen grant mappings. This is needed for using any
virtualized device (e.g. virtio) in Xen guests in a safe manner.

Please note, for the virtio devices the XEN_VIRTIO config should
be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS).

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-9-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
By assigning xen-grant DMA ops we will restrict memory access for
passed device using Xen grant mappings. This is needed for using any
virtualized device (e.g. virtio) in Xen guests in a safe manner.

Please note, for the virtio devices the XEN_VIRTIO config should
be enabled (it forces ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS).

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-9-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices</title>
<updated>2022-06-06T14:07:30+00:00</updated>
<author>
<name>Oleksandr Tyshchenko</name>
<email>oleksandr_tyshchenko@epam.com</email>
</author>
<published>2022-06-02T19:23:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=625ab90ecdf7770bda7ae21c4d5c938aa9b43bb4'/>
<id>625ab90ecdf7770bda7ae21c4d5c938aa9b43bb4</id>
<content type='text'>
Use the presence of "iommus" property pointed to the IOMMU node with
recently introduced "xen,grant-dma" compatible as a clear indicator
of enabling Xen grant mappings scheme for that device and read the ID
of Xen domain where the corresponding backend is running. The domid
(domain ID) is used as an argument to the Xen grant mapping APIs.

To avoid the deferred probe timeout which takes place after reusing
generic IOMMU device tree bindings (because the IOMMU device never
becomes available) enable recently introduced stub IOMMU driver by
selecting XEN_GRANT_DMA_IOMMU.

Also introduce xen_is_grant_dma_device() to check whether xen-grant
DMA ops need to be set for a passed device.

Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-8-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the presence of "iommus" property pointed to the IOMMU node with
recently introduced "xen,grant-dma" compatible as a clear indicator
of enabling Xen grant mappings scheme for that device and read the ID
of Xen domain where the corresponding backend is running. The domid
(domain ID) is used as an argument to the Xen grant mapping APIs.

To avoid the deferred probe timeout which takes place after reusing
generic IOMMU device tree bindings (because the IOMMU device never
becomes available) enable recently introduced stub IOMMU driver by
selecting XEN_GRANT_DMA_IOMMU.

Also introduce xen_is_grant_dma_device() to check whether xen-grant
DMA ops need to be set for a passed device.

Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-8-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/virtio: Enable restricted memory access using Xen grant mappings</title>
<updated>2022-06-06T14:07:30+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2022-06-02T19:23:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fa1f57421e0b1c57843902c89728f823abc32f02'/>
<id>fa1f57421e0b1c57843902c89728f823abc32f02</id>
<content type='text'>
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.

Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-5-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to support virtio in Xen guests add a config option XEN_VIRTIO
enabling the user to specify whether in all Xen guests virtio should
be able to access memory via Xen grant mappings only on the host side.

Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-5-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/grant-dma-ops: Add option to restrict memory access under Xen</title>
<updated>2022-06-06T06:54:52+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2022-06-02T19:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d6aca3504c7ded5f4f46957e3685b9344d9743dd'/>
<id>d6aca3504c7ded5f4f46957e3685b9344d9743dd</id>
<content type='text'>
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
routines for providing grant references as DMA addresses to be used by
frontends (e.g. virtio) in Xen guests.

Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.

The subsequent commit will introduce the use case for xen-grant DMA ops
layer to enable using virtio devices in Xen guests in a safe manner.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-4-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
routines for providing grant references as DMA addresses to be used by
frontends (e.g. virtio) in Xen guests.

Add the needed functionality by providing a special set of DMA ops
handling the needed grant operations for the I/O pages.

The subsequent commit will introduce the use case for xen-grant DMA ops
layer to enable using virtio devices in Xen guests in a safe manner.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/1654197833-25362-4-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen/grants: support allocating consecutive grants</title>
<updated>2022-06-06T06:54:35+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2022-06-02T19:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=02a9e681a3f7998074f39ec265080bf934871530'/>
<id>02a9e681a3f7998074f39ec265080bf934871530</id>
<content type='text'>
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.

As consecutive grants will be needed only in very rare cases (e.g. when
configuring a virtio device with a multi-page ring), optimize for the
normal case of non-consecutive allocations.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-3-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.

As consecutive grants will be needed only in very rare cases (e.g. when
configuring a virtio device with a multi-page ring), optimize for the
normal case of non-consecutive allocations.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-3-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm/xen: Introduce xen_setup_dma_ops()</title>
<updated>2022-06-06T06:54:33+00:00</updated>
<author>
<name>Oleksandr Tyshchenko</name>
<email>oleksandr_tyshchenko@epam.com</email>
</author>
<published>2022-06-02T19:23:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9bf22421dc8a69cade3c994771637e9693ff0216'/>
<id>9bf22421dc8a69cade3c994771637e9693ff0216</id>
<content type='text'>
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The one of the subsequent commits in current series will add
xen-grant DMA ops case.

Also re-use the xen_swiotlb_detect() check on Arm32.

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
[For arm64]
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-2-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch introduces new helper and places it in new header.
The helper's purpose is to assign any Xen specific DMA ops in
a single place. For now, we deal with xen-swiotlb DMA ops only.
The one of the subsequent commits in current series will add
xen-grant DMA ops case.

Also re-use the xen_swiotlb_detect() check on Arm32.

Signed-off-by: Oleksandr Tyshchenko &lt;oleksandr_tyshchenko@epam.com&gt;
Reviewed-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
[For arm64]
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Link: https://lore.kernel.org/r/1654197833-25362-2-git-send-email-olekstysh@gmail.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'for-linus-5.19-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip</title>
<updated>2022-06-04T20:42:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-06-04T20:42:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4ccbe91de91a8f9559052179d15c0229a8ac9f8a'/>
<id>4ccbe91de91a8f9559052179d15c0229a8ac9f8a</id>
<content type='text'>
Pull more xen updates from Juergen Gross:
 "Two cleanup patches for Xen related code and (more important) an
  update of MAINTAINERS for Xen, as Boris Ostrovsky decided to step
  down"

* tag 'for-linus-5.19-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen: replace xen_remap() with memremap()
  MAINTAINERS: Update Xen maintainership
  xen: switch gnttab_end_foreign_access() to take a struct page pointer
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull more xen updates from Juergen Gross:
 "Two cleanup patches for Xen related code and (more important) an
  update of MAINTAINERS for Xen, as Boris Ostrovsky decided to step
  down"

* tag 'for-linus-5.19-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen: replace xen_remap() with memremap()
  MAINTAINERS: Update Xen maintainership
  xen: switch gnttab_end_foreign_access() to take a struct page pointer
</pre>
</div>
</content>
</entry>
<entry>
<title>xen: replace xen_remap() with memremap()</title>
<updated>2022-06-01T05:24:17+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2022-05-30T08:26:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=41925b105e345ebc84cedb64f59d20cb14a62613'/>
<id>41925b105e345ebc84cedb64f59d20cb14a62613</id>
<content type='text'>
xen_remap() is used to establish mappings for frames not under direct
control of the kernel: for Xenstore and console ring pages, and for
grant pages of non-PV guests.

Today xen_remap() is defined to use ioremap() on x86 (doing uncached
mappings), and ioremap_cache() on Arm (doing cached mappings).

Uncached mappings for those use cases are bad for performance, so they
should be avoided if possible. As all use cases of xen_remap() don't
require uncached mappings (the mapped area is always physical RAM),
a mapping using the standard WB cache mode is fine.

As sparse is flagging some of the xen_remap() use cases to be not
appropriate for iomem(), as the result is not annotated with the
__iomem modifier, eliminate xen_remap() completely and replace all
use cases with memremap() specifying the MEMREMAP_WB caching mode.

xen_unmap() can be replaced with memunmap().

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Acked-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
xen_remap() is used to establish mappings for frames not under direct
control of the kernel: for Xenstore and console ring pages, and for
grant pages of non-PV guests.

Today xen_remap() is defined to use ioremap() on x86 (doing uncached
mappings), and ioremap_cache() on Arm (doing cached mappings).

Uncached mappings for those use cases are bad for performance, so they
should be avoided if possible. As all use cases of xen_remap() don't
require uncached mappings (the mapped area is always physical RAM),
a mapping using the standard WB cache mode is fine.

As sparse is flagging some of the xen_remap() use cases to be not
appropriate for iomem(), as the result is not annotated with the
__iomem modifier, eliminate xen_remap() completely and replace all
use cases with memremap() specifying the MEMREMAP_WB caching mode.

xen_unmap() can be replaced with memunmap().

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Acked-by: Stefano Stabellini &lt;sstabellini@kernel.org&gt;
Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xen: switch gnttab_end_foreign_access() to take a struct page pointer</title>
<updated>2022-05-27T09:05:29+00:00</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2022-05-24T11:46:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=49f8b459fc1de5e3712b57c8ccefae9ec45270f8'/>
<id>49f8b459fc1de5e3712b57c8ccefae9ec45270f8</id>
<content type='text'>
Instead of a virtual kernel address use a pointer of the associated
struct page as second parameter of gnttab_end_foreign_access().

Most users have that pointer available already and are creating the
virtual address from it, risking problems in case the memory is
located in highmem.

gnttab_end_foreign_access() itself won't need to get the struct page
from the address again.

Suggested-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Instead of a virtual kernel address use a pointer of the associated
struct page as second parameter of gnttab_end_foreign_access().

Most users have that pointer available already and are creating the
virtual address from it, risking problems in case the memory is
located in highmem.

gnttab_end_foreign_access() itself won't need to get the struct page
from the address again.

Suggested-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping</title>
<updated>2022-05-26T02:18:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-05-26T02:18:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3f306ea2e18568f693f7763d1c2178f349ae8f31'/>
<id>3f306ea2e18568f693f7763d1c2178f349ae8f31</id>
<content type='text'>
Pull dma-mapping updates from Christoph Hellwig:

 - don't over-decrypt memory (Robin Murphy)

 - takes min align mask into account for the swiotlb max mapping size
   (Tianyu Lan)

 - use GFP_ATOMIC in dma-debug (Mikulas Patocka)

 - 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)

* tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping: (23 commits)
  dma-direct: don't over-decrypt memory
  swiotlb: max mapping size takes min align mask into account
  swiotlb: use the right nslabs-derived sizes in swiotlb_init_late
  swiotlb: use the right nslabs value in swiotlb_init_remap
  swiotlb: don't panic when the swiotlb buffer can't be allocated
  dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC
  dma-direct: don't fail on highmem CMA pages in dma_direct_alloc_pages
  swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
  x86: remove cruft from &lt;asm/dma-mapping.h&gt;
  swiotlb: remove swiotlb_init_with_tbl and swiotlb_init_late_with_tbl
  swiotlb: merge swiotlb-xen initialization into swiotlb
  swiotlb: provide swiotlb_init variants that remap the buffer
  swiotlb: pass a gfp_mask argument to swiotlb_init_late
  swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction
  swiotlb: make the swiotlb_init interface more useful
  x86: centralize setting SWIOTLB_FORCE when guest memory encryption is enabled
  x86: remove the IOMMU table infrastructure
  MIPS/octeon: use swiotlb_init instead of open coding it
  arm/xen: don't check for xen_initial_domain() in xen_create_contiguous_region
  swiotlb: rename swiotlb_late_init_with_default_size
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull dma-mapping updates from Christoph Hellwig:

 - don't over-decrypt memory (Robin Murphy)

 - takes min align mask into account for the swiotlb max mapping size
   (Tianyu Lan)

 - use GFP_ATOMIC in dma-debug (Mikulas Patocka)

 - 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)

* tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping: (23 commits)
  dma-direct: don't over-decrypt memory
  swiotlb: max mapping size takes min align mask into account
  swiotlb: use the right nslabs-derived sizes in swiotlb_init_late
  swiotlb: use the right nslabs value in swiotlb_init_remap
  swiotlb: don't panic when the swiotlb buffer can't be allocated
  dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC
  dma-direct: don't fail on highmem CMA pages in dma_direct_alloc_pages
  swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm
  x86: remove cruft from &lt;asm/dma-mapping.h&gt;
  swiotlb: remove swiotlb_init_with_tbl and swiotlb_init_late_with_tbl
  swiotlb: merge swiotlb-xen initialization into swiotlb
  swiotlb: provide swiotlb_init variants that remap the buffer
  swiotlb: pass a gfp_mask argument to swiotlb_init_late
  swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction
  swiotlb: make the swiotlb_init interface more useful
  x86: centralize setting SWIOTLB_FORCE when guest memory encryption is enabled
  x86: remove the IOMMU table infrastructure
  MIPS/octeon: use swiotlb_init instead of open coding it
  arm/xen: don't check for xen_initial_domain() in xen_create_contiguous_region
  swiotlb: rename swiotlb_late_init_with_default_size
  ...
</pre>
</div>
</content>
</entry>
</feed>
