Re: [PATCH v9 9/10] x86, mm, pat: Refactor !pat_enabled handling
From: Thomas Gleixner
Date: Fri May 22 2015 - 04:34:57 EST
On Wed, 13 May 2015, Toshi Kani wrote:
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -182,7 +182,11 @@ void pat_init_cache_modes(void)
> char pat_msg[33];
> u64 pat;
>
> - rdmsrl(MSR_IA32_CR_PAT, pat);
> + if (pat_enabled)
> + rdmsrl(MSR_IA32_CR_PAT, pat);
> + else
> + pat = boot_pat_state;
boot_pat_state is 0 if pat is disabled, but this boot_pat_state multi
purpose usage is really horrible. We do 5 things at once with it and
of course all of it completely undocumented.
pat_msg[32] = 0;
> for (i = 7; i >= 0; i--) {
> cache = pat_get_cache_mode((pat >> (i * 8)) & 7,
> @@ -200,28 +204,58 @@ void pat_init(void)
> bool boot_cpu = !boot_pat_state;
The crap starts here and this really wants to be distangled.
void pat_init(void)
{
static bool boot_done;
if (!boot_done) {
if (!cpu_has_pat)
pat_disable("PAT not supported by CPU.");
if (pat_enabled) {
rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
if (!boot_pat_state)
pat_disable("PAT read returns always zero, disabled.");
}
} else if (!cpu_has_pat && pat_enabled) {
/*
* If this happens we are on a secondary CPU, but
* switched to PAT on the boot CPU. We have no way to
* undo PAT.
*/
pr_err("PAT enabled but not supported by secondary CPU\n");
BUG();
}
if (!pat_enabled) {
.....
} else {
.....
}
if (!boot_done) {
....
boot_done = true;
}
}
And this cleanup wants to be done as a seperate patch before you do
this other stuff.
> @@ -275,16 +309,8 @@ void pat_init(void)
> PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
> }
>
> - /* Boot CPU check */
> - if (!boot_pat_state) {
> - rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
> - if (!boot_pat_state) {
> - pat_disable("PAT read returns always zero, disabled.");
> - return;
> - }
> - }
> -
> - wrmsrl(MSR_IA32_CR_PAT, pat);
> + if (pat_enabled)
> + wrmsrl(MSR_IA32_CR_PAT, pat);
Sigh.
if (!pat_enabled) {
....
} else {
....
}
+ if (pat_enabled)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/