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 <pet...@redhat.com>
>> Cc: Richard Henderson <r...@twiddle.net>
>> Cc: Paolo Bonzini <pbonz...@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>> Cc: Eduardo Habkost <ehabk...@redhat.com>
>> Cc: Marcel Apfelbaum <marcel.apfelb...@gmail.com>
>> Cc: Stefan Weil <s...@weilnetz.de>
>> Cc: Igor Mammedov <imamm...@redhat.com>
>> Cc: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com>
>> Signed-off-by: David Hildenbrand <da...@redhat.com>
>> ---
>> 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 <muri...@linux.ibm.com>
>
--
Thanks,
David / dhildenb
