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

[Christian Borntraeger]

On 02.08.19 10:37, David Hildenbrand wrote:
> On 02.08.19 10:29, Christian Borntraeger wrote:
>>
>>
>> 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.
>>
>> We always call it. We just call it twice for > 8TB
> 
> Yeah, that's what I meant.
> 
>>>
>>> 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 the time being we can block migration for guests > 8TB if that helps (it 
>> should not
>> fail in a guest killing fashion), but we should
>> 1. continue to be able to migrate guests < 8TB
>> 2. continue to be 
>>
>> On the other hand I find "and suddenly it fails if you go beyond this" really
>> unpleasant. So it would be interesting to see the next round of patches to 
>> check how "hacky" those really are.
> 
> I mean migration will work perfectly fine once we fixed it for new QEMU
> versions. It's only the older QEMU versions to/from the > fixed one.

I think that would be fine. We just have to make sure that migration really
fails in a way that the system continues to run. 
> 
> Looking at the log I can see that this was introduced with v2.12.0.
> 
> I would document this in the next release notes: "Migration of unusual
> big VMs (>= 8TB) will not work from/to previous QEMU versions (up to
> v2.12, before that starting such guests didn't even work)."

Yes, sounds good.