[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 04/10] vfio: Query and store the maximum number of DMA map
|
From: |
David Hildenbrand |
|
Subject: |
Re: [PATCH v3 04/10] vfio: Query and store the maximum number of DMA mappings |
|
Date: |
Thu, 17 Dec 2020 20:37:40 +0100 |
> 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.
[PATCH v3 06/10] vfio: Support for RamDiscardMgr in the vIOMMU case, David Hildenbrand, 2020/12/16
[PATCH v3 07/10] softmmu/physmem: Don't use atomic operations in ram_block_discard_(disable|require), David Hildenbrand, 2020/12/16
[PATCH v3 08/10] softmmu/physmem: Extend ram_block_discard_(require|disable) by two discard types, David Hildenbrand, 2020/12/16
[PATCH v3 09/10] virtio-mem: Require only coordinated discards, David Hildenbrand, 2020/12/16