[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH RFC 0/2] s390: stop abusing memory_region_alloca

From: David Hildenbrand
Subject: Re: [qemu-s390x] [PATCH RFC 0/2] s390: stop abusing memory_region_allocate_system_memory()
Date: Fri, 2 Aug 2019 10:37:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

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.

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)."



David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]