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
