Thread (50 messages) 50 messages, 6 authors, 2023-12-26

Re: [PATCH 06/16] iommu/dma: use page allocation function provided by iommu-pages.h

From: Robin Murphy <robin.murphy@arm.com>
Date: 2023-11-28 22:59:43
Also in: asahi, cgroups, kvm, linux-doc, linux-fsdevel, linux-iommu, linux-mm, linux-rockchip, linux-samsung-soc, linux-sunxi, linux-tegra, lkml, virtualization

On 2023-11-28 10:50 pm, Pasha Tatashin wrote:
On Tue, Nov 28, 2023 at 5:34 PM Robin Murphy [off-list ref] wrote:
quoted
On 2023-11-28 8:49 pm, Pasha Tatashin wrote:
quoted
Convert iommu/dma-iommu.c to use the new page allocation functions
provided in iommu-pages.h.
These have nothing to do with IOMMU pagetables, they are DMA buffers and
they belong to whoever called the corresponding dma_alloc_* function.
Hi Robin,

This is true, however, we want to account and observe the pages
allocated by IOMMU subsystem for DMA buffers, as they are essentially
unmovable locked pages. Should we separate IOMMU memory from KVM
memory all together and add another field to /proc/meminfo, something
like "iommu -> iommu pagetable and dma memory", or do we want to
export DMA memory separately from IOMMU page tables?
These are not allocated by "the IOMMU subsystem", they are allocated by 
the DMA API. Even if you want to claim that a driver pinning memory via 
iommu_dma_ops is somehow different from the same driver pinning the same 
amount of memory via dma-direct when iommu.passthrough=1, it's still 
nonsense because you're failing to account the pages which iommu_dma_ops 
gets from CMA, dma_common_alloc_pages(), dynamic SWIOTLB, the various 
pools, and so on.

Thanks,
Robin.
Since, I included DMA memory, I specifically removed mentioning of
IOMMU page tables in the most of places, and only report it as IOMMU
memory. However, since it is still bundled together with SecPageTables
it can be confusing.

Pasha
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help