qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 3/4] x86: fill high bits of mtrr mask


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3 3/4] x86: fill high bits of mtrr mask
Date: Wed, 6 Jul 2016 16:18:42 -0300
User-agent: Mutt/1.6.1 (2016-04-27)

On Tue, Jul 05, 2016 at 08:03:17PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
> 
> 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 <address@hidden>
> Suggested-by: Paolo Bonzini <address@hidden>
[...]
> @@ -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);


> +    } 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



reply via email to

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