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

[Eduardo Habkost]

On Tue, Jul 05, 2016 at 10:49:48AM +0100, Dr. David Alan Gilbert wrote:
> * 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.

I believe Daniel's point is not whether the CPU model matches
real hardware (we don't really care), but whether its ABI is
stable and migration-safe.

So, replying to Daniel: the issue you point out is real, but the
problem here is that both options are bad and we need to choose
the least harmful one.

We can't emulate properly a phys-bits=36 VM in a phys-bits=40
host, and vice versa. So keeping phys-bits the same on migration
is also a bad solution. See the v1 discussion thread:

  Subject: Default for phys-addr-bits? (was Re: [PATCH 4/5] x86:
           Allow physical address bits to be set)
  http://article.gmane.org/gmane.comp.emulators.qemu/421132

-- 
Eduardo