[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
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, (continued)
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Paolo Bonzini, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Michael S. Tsirkin, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Paolo Bonzini, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Michael S. Tsirkin, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Dr. David Alan Gilbert, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Michael S. Tsirkin, 2016/07/05
Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches, Daniel P. Berrange, 2016/07/05
- Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches,
Dr. David Alan Gilbert <=