Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Jul 04, 2016 at 08:16:03PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> 
> QEMU sets the guests physical address bits to 40; this is wrong
> on most hardware, and can be detected by the guest.
> It also stops you using really huge multi-TB VMs.
> 
> Red Hat has had a patch, that Andrea wrote, downstream for a couple
> of years that reads the hosts value and uses that in the guest.  That's
> correct as far as the guest sees it, and lets you create huge VMs.
> 
> The downside, is that if you've got a mix of hosts, say an i7 and a Xeon,
> life gets complicated in migration; prior to 2.6 it all apparently
> worked (although a guest that looked might spot the change).
> In 2.6 Paolo started checking MSR writes and they failed when the
> incoming MTRR mask didn't fit.
> 
> This series:
>    a) Fixes up mtrr masks so that if you're migrating between hosts
>       of different physical address size it tries to do something sensible.
> 
>    b) Lets you specify the guest physical address size via a CPU property, i.e.
>         -cpu SandyBridge,phys-bits=36
> 
>       The default on old machine types is to use the existing 40 bits value.
> 
>    c) Lets you tell qemu to use the same setting as the host, i.e.
>         -cpu SandyBridge,phys-bits=0
>  
>       This is the default on new machine types.

As a general rule we've tried to say that if you pick an explicit CPU
model, we're migration safe. By having the phys-bits default value
always reflect the host CPU value, it feels like we've made the explicit
CPU model choice less safe, just like -cpu host is.

IOW, if choosing a named CPU model, it feels like we should have a
corresponding fixed phys-bit value for that CPU model, even if it
has to be quiet conservative (eg default to bits=36). A phys-bits=0
value should only be used with  -cpu host.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|