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 >
