Re: [Qemu-devel] [PATCH/RFC] s390x: split memory into 4TB chunks

From: David Hildenbrand <david@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	Halil Pasic <pasic@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Thomas Huth <thuth@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH/RFC] s390x: split memory into 4TB chunks
Date: Wed, 6 Dec 2017 13:19:56 +0100	[thread overview]
Message-ID: <f671ca94-c63a-8d68-72d4-7f5c518b3960@redhat.com> (raw)
In-Reply-To: <c040f027-54a5-f7d3-0406-e06fd1064fa6@de.ibm.com>

>>>> This will most certainly break migration, no?
>>>
>>> Probably yes. Thats why the patch has RFC. I was looking for ideas.
>>
>> As other architectures might also run into this problem, wonder if
>>
>> a) bumping up KVM_MEM_MAX_NR_PAGES makes sense.
> 
> The original limitation comes from the fact that this define is used to limit
> the number of bits in the dirty bitmap as some architectures do not provide
> bitops beyond 2^32.

Then my question would be if we can bump it up for all architectures
that support it.

> 
>> b) as I said, transparently handle it in kvm slot handling code.
> 
> adding Paolo to check what he thinks.
>>
>>>>
>>>> 1. I remember the name being used for migration, I might be wrong.
>>>> 2. Migration of guests > 4TB is certainly broken ;)
>>>>
>>>> I wonder if this should rather be handled in the kvm_slot code.
>>>> (silently create an manage two slots)
>>>
>>
>>
> 

-- 

Thanks,

David / dhildenb