qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()


From: David Hildenbrand
Subject: Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()
Date: Fri, 28 Feb 2020 21:16:28 +0100


> Am 28.02.2020 um 20:43 schrieb Peter Xu <address@hidden>:
> 
> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]