Re: [PATCH v3 04/10] vfio: Query and store the maximum number of DMA mappings

[David Hildenbrand <david@redhat.com>]

> Am 17.12.2020 um 20:04 schrieb David Hildenbrand <david@redhat.com>:
> 
> On 17.12.20 18:55, Alex Williamson wrote:
>>> On Wed, 16 Dec 2020 15:11:54 +0100
>>> David Hildenbrand <david@redhat.com> wrote:
>>> 
>>> Let's query the maximum number of DMA mappings by querying the available
>>> mappings when creating the container.
>>> 
>>> In addition, count the number of DMA mappings and warn when we would
>>> exceed it. This is a preparation for RamDiscardMgr which might
>>> create quite some DMA mappings over time, and we at least want to warn
>>> early that the QEMU setup might be problematic. Use "reserved"
>>> terminology, so we can use this to reserve mappings before they are
>>> actually created.
>> 
>> This terminology doesn't make much sense to me, we're not actually
>> performing any kind of reservation.
> 
> I see you spotted the second user which actually performs reservations.
> 
>> 
>>> Note: don't reserve vIOMMU DMA mappings - using the vIOMMU region size
>>> divided by the mapping page size might be a bad indication of what will
>>> happen in practice - we might end up warning all the time.
>> 
>> This suggests we're not really tracking DMA "reservations" at all.
>> Would something like dma_regions_mappings be a more appropriate
>> identifier for the thing you're trying to count?  We might as well also
> 
> Right now I want to count
> - Mappings we know we will definitely have (counted in this patch)
> - Mappings we know we could eventually have later (RamDiscardMgr)
> 
>> keep a counter for dma_iommu_mappings where the sum of those two should
>> stay below dma_max_mappings.
> 
> We could, however, tracking active IOMMU mappings when removing a memory
> region from the address space isn't easily possible - we do a single
> vfio_dma_unmap() which might span multiple mappings. Same applies to
> RamDiscardMgr. Hard to count how many mappings we actually *currently*
> have using that approach.
> 

Thinking about it, might actually be possible when tracking active mappings per iommu / ram discard mgr as well. Will have a look in the new year - thanks.