Re: [PATCH v4 15/15] exec: Ram blocks with resizeable anonymous allocations under POSIX

[David Hildenbrand]

On 25.03.20 16:34, Murilo Opsfelder Araújo wrote:
> On Thursday, March 5, 2020 11:29:45 AM -03 David Hildenbrand wrote:
>> We can now make use of resizeable anonymous allocations to implement
>> actually resizeable ram blocks. Resizeable anonymous allocations are
>> not implemented under WIN32 yet and are not available when using
>> alternative allocators. Fall back to the existing handling.
>>
>> We also have to fallback to the existing handling in case any ram block
>> notifier does not support resizing (esp., AMD SEV, HAX) yet. Remember
>> in RAM_RESIZEABLE_ALLOC if we are using resizeable anonymous allocations.
>>
>> Try to grow early, as that can easily fail if out of memory. Shrink late
>> and ignore errors (nothing will actually break). Warn only.
>>
>> The benefit of actually resizeable ram blocks is that e.g., under Linux,
>> only the actual size will be reserved (even if
>> "/proc/sys/vm/overcommit_memory" is set to "never"). Additional memory will
>> be reserved when trying to resize, which allows to have ram blocks that
>> start small but can theoretically grow very large.
>>
>> Note1: We are not able to create resizeable ram blocks with pre-allocated
>>        memory yet, so prealloc is not affected.
>> Note2: mlock should work as it used to as os_mlock() does a
>>        mlockall(MCL_CURRENT | MCL_FUTURE), which includes future
>>        mappings.
>> Note3: Nobody should access memory beyond used_length. Memory notifiers
>>        already properly take care of this, only ram block notifiers
>>        violate this constraint and, therefore, have to be special-cased.
>>        Especially, any ram block notifier that might dynamically
>>        register at runtime (e.g., vfio) has to support resizes. Add an
>>        assert for that. Both, HAX and SEV register early, so they are
>>        fine.
>>
>> Reviewed-by: Peter Xu <address@hidden>
>> Cc: Richard Henderson <address@hidden>
>> Cc: Paolo Bonzini <address@hidden>
>> Cc: "Dr. David Alan Gilbert" <address@hidden>
>> Cc: Eduardo Habkost <address@hidden>
>> Cc: Marcel Apfelbaum <address@hidden>
>> Cc: Stefan Weil <address@hidden>
>> Cc: Igor Mammedov <address@hidden>
>> Cc: Shameerali Kolothum Thodi <address@hidden>
>> Signed-off-by: David Hildenbrand <address@hidden>
>> ---
>>  exec.c                    | 65 ++++++++++++++++++++++++++++++++++++---
>>  hw/core/numa.c            |  7 +++++
>>  include/exec/cpu-common.h |  2 ++
>>  include/exec/memory.h     |  8 +++++
>>  4 files changed, 77 insertions(+), 5 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 9c3cc79193..6c6b6e12d2 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -2001,6 +2001,16 @@ void qemu_ram_unset_migratable(RAMBlock *rb)
>>      rb->flags &= ~RAM_MIGRATABLE;
>>  }
>>
>> +bool qemu_ram_is_resizeable(RAMBlock *rb)
>> +{
>> +    return rb->flags & RAM_RESIZEABLE;
>> +}
>> +
>> +bool qemu_ram_is_resizeable_alloc(RAMBlock *rb)
>> +{
>> +    return rb->flags & RAM_RESIZEABLE_ALLOC;
>> +}
>> +
>>  /* Called with iothread lock held.  */
>>  void qemu_ram_set_idstr(RAMBlock *new_block, const char *name, DeviceState
>> *dev) {
>> @@ -2094,6 +2104,7 @@ static void qemu_ram_apply_settings(void *host, size_t
>> length) */
>>  int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
>>  {
>> +    const bool shared = block->flags & RAM_SHARED;
> 
> Do you think a new function, for example, qemu_ram_is_shared() would be
> welcome to check for RAM_SHARED flag as well?  Similar to what is done
> in qemu_ram_is_resizeable() and qemu_ram_is_resizeable_alloc().

We have that one already, and I'll just reuse it :)

Thanks!

> 
> Apart from that,
> 
> Acked-by: Murilo Opsfelder Araujo <address@hidden>
> 

-- 
Thanks,

David / dhildenb