Re: [PATCH v3 4/5] mtrr, x86: Clean up mtrr_type_lookup()

[Toshi Kani <toshi.kani@hp.com>]

On Mon, 2015-03-16 at 21:24 +0000, Kani, Toshimitsu wrote:
> > On Mar 16, 2015, at 3:58 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >> * Toshi Kani <toshi.kani@hp.com> wrote:
 :
> 
> >> +    if (!(mtrr_state.have_fixed) ||
> >> +        !(mtrr_state.enabled & MTRR_STATE_MTRR_FIXED_ENABLED))
> > 
> > Btw., can MTRR_STATE_MTRR_FIXED_ENABLED ever be set in 
> > mtrr_state.enabled, without mtrr_state.have_fixed being set?
> 
> Yes, I believe the arch allows the fixed entries disabled
> while MTRRs are enabled.  I expect the most of systems 
> implement the fixed entries, though.

Sorry, I noticed I had mis-read your question before...

No, MTRR_STATE_MTRR_FIXED_ENABLED may not be set without
mtrr_state.have_fixed being set.  mtrr_state.have_fixed indicates if the
CPU supports MTRR fixed ranges.  So, they can be only enabled when the
CPU has ones.

> > AFAICS get_mtrr_state() will only ever fill in mtrr_state with fixed 
> > MTRRs if mtrr_state.have_fixed != 0 - but I might be mis-reading the 
> > (rather convoluted) flow of code ...
> 
> I will check the code next week.

Yes, you are right that get_mtrr_state() only fills in
mtrr_state.fixed_ranges[] when mtrr_state.have_fixed is set.  This is
because the MSRs containing the fixed ranges are only valid when this
flag is set. 

Thanks,
-Toshi



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>