* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Tue, Jul 05, 2016 at 08:03:17PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> > Fill the bits between 51..number-of-physical-address-bits in the
> > MTRR_PHYSMASKn variable range mtrr masks so that they're consistent
> > in the migration stream irrespective of the physical address space
> > of the source VM in a migration.
> >
> > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
> [...]
> > @@ -2084,6 +2085,28 @@ static int kvm_get_msrs(X86CPU *cpu)
> > }
> >
> > assert(ret == cpu->kvm_msr_buf->nmsrs);
> > + /*
> > + * MTRR masks: Each mask consists of 5 parts
> > + * a 10..0: must be zero
> > + * b 11 : valid bit
> > + * c n-1.12: actual mask bits
> > + * d 51..n: reserved must be zero
> > + * e 63.52: reserved must be zero
> > + *
> > + * 'n' is the number of physical bits supported by the CPU and is
> > + * apparently always <= 52. We know our 'n' but don't know what
> > + * the destinations 'n' is; it might be smaller, in which case
> > + * it masks (c) on loading. It might be larger, in which case
> > + * we fill 'd' so that d..c is consistent irrespetive of the 'n'
> > + * we're migrating to.
> > + */
> > + if (cpu->fill_mtrr_mask && cpu->phys_bits <
> > TARGET_PHYS_ADDR_SPACE_BITS) {
>
> As we already ensure phys_bits <= TARGET_PHYS_ADDR_SPACE_BITS in
> patch 1/4, what about just doing this:
>
> assert(cpu->phys_bits <= TARGET_PHYS_ADDR_SPACE_BITS)
>
>
> > + mtrr_top_bits = MAKE_64BIT_MASK(cpu->phys_bits,
> > + TARGET_PHYS_ADDR_SPACE_BITS -
> > cpu->phys_bits);
>
> What's the actual meaning of TARGET_PHYS_ADDR_SPACE_BITS? Can it
> ever change in the future? Should a change in
> TARGET_PHYS_ADDR_SPACE_BITS really change the migration format?
>
> To make sure we won't have any surprises if
> TARGET_PHYS_ADDR_SPACE_BITS change, I would change the code to:
>
> QEMU_BUILD_BUG_ON(TARGET_PHYS_ADDR_SPACE_BITS > 52);
> assert(cpu->phs_bits <= TARGET_PHYS_ADDR_SPACE_BITS);
> mtrr_top_bits = MAKE_64BIT_MASK(cpu->phys_bits, 52 - cpu->phys_bits);
Done.
All limits tend to stretch with time, so no it wouldn't surprise me if that
happened some day.
Dave
>
>
> > + } else {
> > + mtrr_top_bits = 0;
> > + }
> > +
> > for (i = 0; i < ret; i++) {
> > uint32_t index = msrs[i].index;
> > switch (index) {
> > @@ -2279,7 +2302,8 @@ static int kvm_get_msrs(X86CPU *cpu)
> > break;
> > case MSR_MTRRphysBase(0) ... MSR_MTRRphysMask(MSR_MTRRcap_VCNT -
> > 1):
> > if (index & 1) {
> > - env->mtrr_var[MSR_MTRRphysIndex(index)].mask =
> > msrs[i].data;
> > + env->mtrr_var[MSR_MTRRphysIndex(index)].mask =
> > msrs[i].data |
> > +
> > mtrr_top_bits;
> > } else {
> > env->mtrr_var[MSR_MTRRphysIndex(index)].base =
> > msrs[i].data;
> > }
> > --
> > 2.7.4
> >
>
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
