> Am 28.02.2020 um 20:43 schrieb Peter Xu <pet...@redhat.com>:
>
> On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
>> Let's implement ram_block_resized(), allowing resizeable mappings.
>>
>> For resizeable mappings, we reserve $max_size IOVA address space, but only
>> map $size of it. When resizing, unmap the old part and remap the new
>> part. We'll need a new ioctl to do this atomically (e.g., to resize
>> while the guest is running - not allowed for now).
>
> Curious: I think it's true for now because resizing only happens
> during reboot or destination VM during migration (but before
> switching). However is that guaranteed too in the future?
>
E.g., virtio-mem will run mutual exclusive with vfio until vfio won‘t pin all
guest memory anymore blindly (iow, is compatible with memory overcommit and
discarding of ram blocks).
> [...]
>
>> @@ -631,7 +658,7 @@ int qemu_vfio_dma_map(QEMUVFIOState *s, void *host,
>> size_t size,
>> qemu_vfio_remove_mapping(s, mapping);
>> goto out;
>> }
>> - s->low_water_mark += size;
>> + s->low_water_mark += max_size;
>
> I think it's fine to only increase the low water mark here, however
> imo it would be better to also cache the max size in IOVAMapping too,
> then in resize() we double check new_size <= max_size? It also makes
> IOVAMapping more self contained.
>
I‘ll have a look how much additional code that will imply - if it‘s simple,
I‘ll do it.
Thanks!
> Thanks,
>
> --
> Peter Xu
>
