lkml.org 
[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.26, PAT and AMD family 6


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


\
 
 \ /
  Last update: 2008-05-08 02:19    [W:0.085 / U:0.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site