Re: [Qemu-devel] [PATCH] fix guest physical bits to match host, to go beyond 1TB guests

[Andrea Arcangeli <aarcange@redhat.com>]

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