qemu-devel
[Top][All Lists]
Advanced

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

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


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH/RFC] s390x: split memory into 4TB chunks
Date: Wed, 6 Dec 2017 14:48:16 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


On 12/06/2017 02:35 PM, Paolo Bonzini wrote:
> On 06/12/2017 13:15, Christian Borntraeger wrote:
>>> 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.
>>
>>> b) as I said, transparently handle it in kvm slot handling code.
>> adding Paolo to check what he thinks.
> 
> It's a bit of a first-world problem, :) 

If a genie comes along and offers you to fufill 3 wishes, as an IT guy
you say: "I want a memory cardridge that is never full".
The genie say "ok, what is your 2nd wish". You say "A 2nd memory cartridge"....


> and working around it in QEMU
> makes is easy enough that it's okay in my opinion.

Since the dirty logging is synched between the qemu memory regions and the 
KVM slots I will look into something like keep the original memslots and create 
a
new one as soon as we cross the current KVM_MEM_MAX_NR_PAGES size.

> 
> Bumping up KVM_MEM_MAX_NR_PAGES if the bitops allows it should be a good
> idea too, but it requires auditing the code for overflows and truncations.
> 
> Paolo
> 




reply via email to

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