-On Tue, Jul 16, 2013 at 07:48:27PM +0200, Paolo Bonzini wrote: > Il 16/07/2013 19:46, Paolo Bonzini ha scritto: > >>> >> (see PUD with bit >=40 set) > >> > > >> > I am not sure I understand what caused this: if we are advertising 40 > >> > physical bits to the guest, why are we ending up with a PUD with > >> > bit >= 40 set? > > Because we create a guest that has bigger memory than what we advertise > > in CPUID. > > > > Also, note that the guest does not really care about this CPUID. It is > only used by KVM itself to decide which bits in the page tables are > reserved.
Yes, I suppose guests thinks if there's >1TB of RAM there are enough bits in the pagetables to map whatever RAM "range" was found. About migrating >1TB guests it will be possible as soon as qemu starts to use the remap_anon_pages+MADV_USERFAULT two features I posted on linux-kernel recently. With those two features, qemu should start to provide postcopy live migration by default and after pre-copy is complete, it will never need to freeze a guest in the source node anymore.
