Re: [qemu-s390x] [PATCH RFC 0/2] s390: stop abusing memory_region_allocate_system_memory()

[David Hildenbrand]

On 02.08.19 10:04, David Hildenbrand wrote:
> On 29.07.19 16:52, Igor Mammedov wrote:
>> While looking into unifying guest RAM allocation to use hostmem backends
>> for initial RAM (especially when -mempath is used) and retiring
>> memory_region_allocate_system_memory() API, leaving only single hostmem 
>> backend,
>> I was inspecting how currently it is used by boards and it turns out several
>> boards abuse it by calling the function several times (despite documented 
>> contract
>> forbiding it).
>>
>> s390 is one of such boards where KVM limitation on memslot size got 
>> propagated
>> to board design and memory_region_allocate_system_memory() was abused to 
>> satisfy
>> KVM requirement for max RAM chunk where memory region alias would suffice.
>>
>> Unfortunately, memory_region_allocate_system_memory() usage created migration
>> dependency where guest RAM is transferred in migration stream as several 
>> RAMBlocks
>> if it's more than KVM_SLOT_MAX_BYTES.
> 
> So if I understand it correctly, we only call
> memory_region_allocate_system_memory() in case the guest initial memory
> size exceeds KVM_SLOT_MAX_BYTES - ~8TB.
> 
> Do we *really* care about keeping migration of systems running that most
> probably nobody (except Christian ;) ) really uses? (especially not in
> production).
> 
> I am fine keeping migration running if it's easy, but introducing hacks
> (reading below) for such obscure use cases - I don't know.
> 
> @Christian: Please prove me wrong. :)

For reference:

https://access.redhat.com/articles/rhel-kvm-limits

RHEL 7/8 supports up to 2TB maximum memory in KVM guests.


https://www.suse.com/releasenotes/s390x/SUSE-SLES/15-SP1/

SLES 15 seems to support up to 4TB in a VM


If migration failing would mean "abort migration, continue on migration
source", I could sleep good at night. (as long as nothing crashes)

-- 

Thanks,

David / dhildenb