On Mon, Jul 04, 2016 at 05:05:36PM -0300, Eduardo Habkost wrote: > On Mon, Jul 04, 2016 at 11:02:00PM +0300, Michael S. Tsirkin wrote: > > On Mon, Jul 04, 2016 at 08:16:05PM +0100, Dr. David Alan Gilbert (git) > > wrote: > > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > > > The CPU GPs if we try and set a bit in a variable MTRR mask above > > > the limit of physical address bits on the host. We hit this > > > when loading a migration from a host with a larger physical > > > address limit than our destination (e.g. a Xeon->i7 of same > > > generation) but previously used to get away with it > > > until 48e1a45 started checking that msr writes actually worked. > > > > > > It seems in our case the GP probably comes from KVM emulating > > > that GP. > > > > > > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > > > Why don't we mask with host bits? This is the kvm limitation, > > isn't it? This will make it possible to CC stable as well. > > KVM validates the value written to the MSR using the guest CPUID > data, not the host bits. If we trim using the host bits, we would > still crash if cpu->phys_bits < host_phys_bits.
I didn't realise. Will have to re-do the review. > -- > Eduardo
