qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches
Date: Tue, 5 Jul 2016 10:49:48 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

* Daniel P. Berrange (address@hidden) wrote:
> On Mon, Jul 04, 2016 at 08:16:03PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > 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.

phys-bits doesn't follow a cpu model in real hardware
  e.g. a SandyBridge Xeon and a SandyBridge i7 are different.

So unless we suddenly created at least 2x as many cpu models we can't
do that.

Dave

> 
> 
> 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 :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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