Re: [RFC] Cachemap for 2.6.12rc4-mm1. Was Re: [PATCH] enhance x86MTRR handling

[H. Peter Anvin]

Dave Jones wrote:

> +	switch (boot_cpu_data.x86_vendor) {
> +	case X86_VENDOR_AMD:
> +		wrmsr(IA32_CR_PAT, AMD_PAT_31_0, AMD_PAT_63_32);
> +		atomic_inc(&pat_cpus_enabled);
> +		break;
> +	case X86_VENDOR_INTEL:
> +		wrmsr(IA32_CR_PAT, INTEL_PAT_31_0, INTEL_PAT_63_32);
> +		atomic_inc(&pat_cpus_enabled);
> +		break;
> +	default:
> +		printk("Unknown vendor in setup_pat()\n");
> +	}

Drop the vendor check; PAT is a generic x86 feature.  If AMD is not 
compatible (see below), then use X86_VENDOR_AMD: and default:.

> +
> +	/* checks copied from arch/i386/kernel/cpu/mtrr/main.c */
> +	/* do these only apply to mtrrs or pat as well? */

It would apply to both; the chipset wouldn't even know how it got invoked.

> +/* Here is the PAT's default layout on ia32 cpus when we are done.
> + * PAT0: Write Back
> + * PAT1: Write Combine
> + * PAT2: Uncached
> + * PAT3: Uncacheable
> + * PAT4: Write Through
> + * PAT5: Write Protect
> + * PAT6: Uncached
> + * PAT7: Uncacheable

Bad move.  Some (Intel) processors drop the top bit, so it's much better 
to pick the protection methods one cares about (usually WB, WC, UC) and 
stick them in the first four, then duplicate the whole thing in the 
second half.

Unless you actually expect someone to use WT or WP, no need to tickle 
this particular bug.

> + * Note: On Athlon cpus PAT2/PAT3 & PAT6/PAT7 are both Uncacheable since 
> + *	 there is no uncached type.

If one sets the PAT to "uncached", does one get the same function as 
"uncachable"?

	-hpa
-
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/