Re: 2.6.26, PAT and AMD family 6

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 7 May 2008, H. Peter Anvin wrote:
> > 
> > What a lovely way of syncing reality with your definitions. The kernel
> > _does_ see that my CPU features PAT, it just refuses to use it because
> > it doesn't trust it enough. Vital difference. Maybe not to the kernel,
> > but definitely to me, the user. /proc/cpuinfo is a user interface.
> > 
> 
> No, /proc/cpuinfo is informing the user about the kernel's view of the CPU.
> It has always been the "cooked" view of CPUID, whether or not you like it.

Indeed. If people want to know what the CPU itself reports, they should 
just use the "cpuid" instruction directly. The /proc/cpuinfo file has 
been a window into the kernels notion of what is going on, and disabling 
kernel features have disabled the bits in that file as appropriate (eg 
"clearcpuid=xyzzy" and "mem=nopentium" etc).

Of course, the *common* case is that the two will match 100% in features. 
But the kernel view has some of its very own set of CPU features too.

And it is possible that the "PAT as the kernel sees it" should be a 
*separate* bit from "PAT as the cpu itself reports to support it". We do 
that for quite a lot of the "synthesized" features, eg there is the "TSC" 
feature as the CPU reports it, and then we have the "CONSTANT_TSC" feature 
that is the kernel version of it that says that we have a TSC _and_ it 
runs at a constant rate too (or the "UP" bit, or the "Mfence synchronizes 
RDTSC" bit etc etc).

So it's possible that we should do the same thing for PAT - and allow 
people to see the CPU view _and_ the kernel view as two separate issues. 
In many ways that would be the logical thing to do. Hmm?

		Linus