* [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
@ 2009-05-12 7:14 Jaswinder Singh Rajput
2009-05-12 13:39 ` Borislav Petkov
2009-05-13 6:21 ` Andrew Morton
0 siblings, 2 replies; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-05-12 7:14 UTC (permalink / raw)
To: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
Here are 2 patches for adding new field extended_cpuid_level, please
choose PATCH whichever is more appropriate:
PATCH 1:
Subject: [PATCH] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
extended_cpuid_level also gives useful information like cpuid_level
and very useful for AMD processors.
Adding extended_cpuid_level in /proc/cpuinfo completes cpuid_level info.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/proc.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 523bf39..1279e16 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -39,6 +39,7 @@ static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
"fpu\t\t: %s\n"
"fpu_exception\t: %s\n"
"cpuid level\t: %d\n"
+ "ext cpuid level\t: 0x%x\n"
"wp\t\t: %s\n",
c->fdiv_bug ? "yes" : "no",
c->hlt_works_ok ? "no" : "yes",
@@ -47,6 +48,7 @@ static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
c->hard_math ? "yes" : "no",
fpu_exception ? "yes" : "no",
c->cpuid_level,
+ c->extended_cpuid_level,
c->wp_works_ok ? "yes" : "no");
}
#else
@@ -56,8 +58,10 @@ static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
"fpu\t\t: yes\n"
"fpu_exception\t: yes\n"
"cpuid level\t: %d\n"
+ "ext cpuid level\t: 0x%x\n"
"wp\t\t: yes\n",
- c->cpuid_level);
+ c->cpuid_level,
+ c->extended_cpuid_level);
}
#endif
--
1.6.0.6
OR
PATCH 2:
Subject: [PATCH] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
extended_cpuid_level also gives useful information like cpuid_level
and very useful for AMD processors.
Adding extended_cpuid_level in /proc/cpuinfo completes cpuid_level info.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/proc.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 523bf39..a965bf7 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -102,7 +102,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
show_cpuinfo_core(m, c, cpu);
show_cpuinfo_misc(m, c);
- seq_printf(m, "flags\t\t:");
+ seq_printf(m, "ext cpuid level\t: 0x%x\n"
+ "flags\t\t:",
+ c->extended_cpuid_level);
for (i = 0; i < 32*NCAPINTS; i++)
if (cpu_has(c, i) && x86_cap_flags[i] != NULL)
seq_printf(m, " %s", x86_cap_flags[i]);
--
1.6.0.6
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 7:14 [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo Jaswinder Singh Rajput
@ 2009-05-12 13:39 ` Borislav Petkov
2009-05-12 13:49 ` Jaswinder Singh Rajput
2009-05-13 6:21 ` Andrew Morton
1 sibling, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2009-05-12 13:39 UTC (permalink / raw)
To: Jaswinder Singh Rajput; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
Hi,
On Tue, May 12, 2009 at 12:44:42PM +0530, Jaswinder Singh Rajput wrote:
>
> Here are 2 patches for adding new field extended_cpuid_level, please
> choose PATCH whichever is more appropriate:
>
> PATCH 1:
> Subject: [PATCH] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
>
> extended_cpuid_level also gives useful information like cpuid_level
> and very useful for AMD processors.
>
> Adding extended_cpuid_level in /proc/cpuinfo completes cpuid_level info.
and this is needed because... ?!
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 13:39 ` Borislav Petkov
@ 2009-05-12 13:49 ` Jaswinder Singh Rajput
2009-05-12 14:10 ` Borislav Petkov
0 siblings, 1 reply; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-05-12 13:49 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
On Tue, 2009-05-12 at 15:39 +0200, Borislav Petkov wrote:
> Hi,
>
> On Tue, May 12, 2009 at 12:44:42PM +0530, Jaswinder Singh Rajput wrote:
> >
> > Here are 2 patches for adding new field extended_cpuid_level, please
> > choose PATCH whichever is more appropriate:
> >
> > PATCH 1:
> > Subject: [PATCH] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
> >
> > extended_cpuid_level also gives useful information like cpuid_level
> > and very useful for AMD processors.
> >
> > Adding extended_cpuid_level in /proc/cpuinfo completes cpuid_level info.
>
> and this is needed because... ?!
>
why we need cpuid_level ?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 13:49 ` Jaswinder Singh Rajput
@ 2009-05-12 14:10 ` Borislav Petkov
2009-05-12 16:40 ` H. Peter Anvin
0 siblings, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2009-05-12 14:10 UTC (permalink / raw)
To: Jaswinder Singh Rajput; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
On Tue, May 12, 2009 at 07:19:37PM +0530, Jaswinder Singh Rajput wrote:
> On Tue, 2009-05-12 at 15:39 +0200, Borislav Petkov wrote:
> > Hi,
> >
> > On Tue, May 12, 2009 at 12:44:42PM +0530, Jaswinder Singh Rajput wrote:
> > >
> > > Here are 2 patches for adding new field extended_cpuid_level, please
> > > choose PATCH whichever is more appropriate:
> > >
> > > PATCH 1:
> > > Subject: [PATCH] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
> > >
> > > extended_cpuid_level also gives useful information like cpuid_level
> > > and very useful for AMD processors.
> > >
> > > Adding extended_cpuid_level in /proc/cpuinfo completes cpuid_level info.
> >
> > and this is needed because... ?!
> >
>
> why we need cpuid_level ?
It is already visible in userspace. I think you've got an answer to a
very similar question already:
http://marc.info/?l=linux-kernel&m=124206571628464
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 14:10 ` Borislav Petkov
@ 2009-05-12 16:40 ` H. Peter Anvin
2009-05-12 18:13 ` Borislav Petkov
2009-06-05 19:20 ` Jaswinder Singh Rajput
0 siblings, 2 replies; 18+ messages in thread
From: H. Peter Anvin @ 2009-05-12 16:40 UTC (permalink / raw)
To: Borislav Petkov
Cc: Jaswinder Singh Rajput, Ingo Molnar, x86 maintainers, LKML
Borislav Petkov wrote:
>>>
>> why we need cpuid_level ?
>
> It is already visible in userspace. I think you've got an answer to a
> very similar question already:
>
> http://marc.info/?l=linux-kernel&m=124206571628464
>
extended_cpuid_level should be motivated, but probably does make sense.
It hardly "completes" /proc/cpuinfo; especially if you consider that
there are at least three additional ranges in wide use (two used by a
single vendor only, and the third by virtualization software.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 16:40 ` H. Peter Anvin
@ 2009-05-12 18:13 ` Borislav Petkov
2009-05-12 18:47 ` H. Peter Anvin
2009-06-05 19:20 ` Jaswinder Singh Rajput
1 sibling, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2009-05-12 18:13 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jaswinder Singh Rajput, Ingo Molnar, x86 maintainers, LKML
Hi,
On Tue, May 12, 2009 at 09:40:40AM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> >>>
> >> why we need cpuid_level ?
> >
> > It is already visible in userspace. I think you've got an answer to a
> > very similar question already:
> >
> > http://marc.info/?l=linux-kernel&m=124206571628464
> >
>
> extended_cpuid_level should be motivated, but probably does make sense.
I still fail to see the need for adding that to /proc/cpuinfo,
especially if you can do the whole exercise from userspace. But I'm sure
you have a good example.
> It hardly "completes" /proc/cpuinfo; especially if you consider that
> there are at least three additional ranges in wide use (two used by a
> single vendor only, and the third by virtualization software.)
I think both vendors use the two ranges :-o).
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 18:13 ` Borislav Petkov
@ 2009-05-12 18:47 ` H. Peter Anvin
2009-05-12 19:49 ` Borislav Petkov
0 siblings, 1 reply; 18+ messages in thread
From: H. Peter Anvin @ 2009-05-12 18:47 UTC (permalink / raw)
To: Borislav Petkov
Cc: Jaswinder Singh Rajput, Ingo Molnar, x86 maintainers, LKML
Borislav Petkov wrote:
>
>> It hardly "completes" /proc/cpuinfo; especially if you consider that
>> there are at least three additional ranges in wide use (two used by a
>> single vendor only, and the third by virtualization software.)
>
> I think both vendors use the two ranges :-o).
>
No, I'm taking about the 0x8086xxxx and 0xC000xxxx used by two other
vendors (neither of which you and I work for, and at least one of which
is defunct.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 18:47 ` H. Peter Anvin
@ 2009-05-12 19:49 ` Borislav Petkov
0 siblings, 0 replies; 18+ messages in thread
From: Borislav Petkov @ 2009-05-12 19:49 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Borislav Petkov, Jaswinder Singh Rajput, Ingo Molnar,
x86 maintainers, LKML
Hi,
On Tue, May 12, 2009 at 8:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Borislav Petkov wrote:
>>
>>> It hardly "completes" /proc/cpuinfo; especially if you consider that
>>> there are at least three additional ranges in wide use (two used by a
>>> single vendor only, and the third by virtualization software.)
>>
>> I think both vendors use the two ranges :-o).
>>
>
> No, I'm taking about the 0x8086xxxx and 0xC000xxxx used by two other
> vendors (neither of which you and I work for, and at least one of which
> is defunct.)
Ah, yes. Gotcha.
--
Regards/Gruss,
Boris
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 7:14 [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo Jaswinder Singh Rajput
2009-05-12 13:39 ` Borislav Petkov
@ 2009-05-13 6:21 ` Andrew Morton
2009-05-13 8:03 ` Andi Kleen
2009-06-05 18:38 ` Jaswinder Singh Rajput
1 sibling, 2 replies; 18+ messages in thread
From: Andrew Morton @ 2009-05-13 6:21 UTC (permalink / raw)
To: Jaswinder Singh Rajput; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> + "ext cpuid level\t: 0x%x\n"
It's unobvious what "ext" means. External?
Can we make it "extended cpuid level"?
One would hope that google(extended cpuid level) tells you what an
extended cpuid level is, but alas, unclear.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-13 6:21 ` Andrew Morton
@ 2009-05-13 8:03 ` Andi Kleen
2009-06-05 18:38 ` Jaswinder Singh Rajput
1 sibling, 0 replies; 18+ messages in thread
From: Andi Kleen @ 2009-05-13 8:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaswinder Singh Rajput, Ingo Molnar, H. Peter Anvin,
x86 maintainers, LKML
Andrew Morton <akpm@linux-foundation.org> writes:
> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>
>> + "ext cpuid level\t: 0x%x\n"
>
> It's unobvious what "ext" means. External?
>
> Can we make it "extended cpuid level"?
>
> One would hope that google(extended cpuid level) tells you what an
> extended cpuid level is, but alas, unclear.
AMD has an own cpuid range in 0x8000_0000+. But it's only useful
if you actually access it using cpuid. Everyone who needs it
already needs to call cpuid and if they do that they
can as well retrieve it by themselves.
Without accessing CPUID it has no value at whatsoever. It would
also seem pretty dumb to spend a few thousand cycles getting
it from the kernel when you can as well get it directly
from CPUID and you need to have that code anyways.
The useful information in 8000_0000+ is all reported by the kernel
anyways.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-13 6:21 ` Andrew Morton
2009-05-13 8:03 ` Andi Kleen
@ 2009-06-05 18:38 ` Jaswinder Singh Rajput
2009-06-05 20:55 ` H. Peter Anvin
1 sibling, 1 reply; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-06-05 18:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, H. Peter Anvin, x86 maintainers, LKML
Hello Andrew,
On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>
> > + "ext cpuid level\t: 0x%x\n"
>
> It's unobvious what "ext" means. External?
>
> Can we make it "extended cpuid level"?
extended cpuid level will look like this :
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
extended cpuid level: 0x80000008
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
Is this OK ?
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-05-12 16:40 ` H. Peter Anvin
2009-05-12 18:13 ` Borislav Petkov
@ 2009-06-05 19:20 ` Jaswinder Singh Rajput
1 sibling, 0 replies; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-06-05 19:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Borislav Petkov, Ingo Molnar, x86 maintainers, LKML
On Tue, 2009-05-12 at 09:40 -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> >>>
> >> why we need cpuid_level ?
> >
> > It is already visible in userspace. I think you've got an answer to a
> > very similar question already:
> >
> > http://marc.info/?l=linux-kernel&m=124206571628464
> >
>
> extended_cpuid_level should be motivated, but probably does make sense.
> It hardly "completes" /proc/cpuinfo; especially if you consider that
> there are at least three additional ranges in wide use (two used by a
> single vendor only, and the third by virtualization software.)
>
So how can we complete it.
--
JSR
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-05 18:38 ` Jaswinder Singh Rajput
@ 2009-06-05 20:55 ` H. Peter Anvin
2009-06-06 4:23 ` Jaswinder Singh Rajput
0 siblings, 1 reply; 18+ messages in thread
From: H. Peter Anvin @ 2009-06-05 20:55 UTC (permalink / raw)
To: Jaswinder Singh Rajput; +Cc: Andrew Morton, Ingo Molnar, x86 maintainers, LKML
Jaswinder Singh Rajput wrote:
> Hello Andrew,
>
> On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
>> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>>
>>> + "ext cpuid level\t: 0x%x\n"
>> It's unobvious what "ext" means. External?
>>
>> Can we make it "extended cpuid level"?
>
> extended cpuid level will look like this :
>
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> extended cpuid level: 0x80000008
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
>
The more I'm thinking about this I think it was a mistake to put cpuid
level: there in the first place, too. My opinion is increasingly to
leave this to x86info or other user-space tools.
-hpa
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-05 20:55 ` H. Peter Anvin
@ 2009-06-06 4:23 ` Jaswinder Singh Rajput
2009-06-10 16:40 ` Jaswinder Singh Rajput
0 siblings, 1 reply; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-06-06 4:23 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Andrew Morton, Ingo Molnar, x86 maintainers, LKML
On Fri, 2009-06-05 at 13:55 -0700, H. Peter Anvin wrote:
> Jaswinder Singh Rajput wrote:
> > Hello Andrew,
> >
> > On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> >> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> >>
> >>> + "ext cpuid level\t: 0x%x\n"
> >> It's unobvious what "ext" means. External?
> >>
> >> Can we make it "extended cpuid level"?
> >
> > extended cpuid level will look like this :
> >
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 5
> > wp : yes
> > extended cpuid level: 0x80000008
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
> >
>
> The more I'm thinking about this I think it was a mistake to put cpuid
> level: there in the first place, too. My opinion is increasingly to
> leave this to x86info or other user-space tools.
>
cpuid level is as important as cpu family, model and stepping.
For Intel, in some cases cpuid level is more important then cpu family,
model and stepping. Like you cannot tell by looking at cpu family, model
and stepping which model is new and which is old like 05_01 or 06_1A or
0F_03H ?
But by looking at cpuid level and extended cpuid level you can tell
which is new and which is old and which supports more features.
So cpuid level and extended cpuid level is better scale than cpu family,
model and stepping. So I think hiding this valuable information is a
crime.
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-06 4:23 ` Jaswinder Singh Rajput
@ 2009-06-10 16:40 ` Jaswinder Singh Rajput
2009-06-10 17:14 ` H. Peter Anvin
0 siblings, 1 reply; 18+ messages in thread
From: Jaswinder Singh Rajput @ 2009-06-10 16:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Andrew Morton, Ingo Molnar, x86 maintainers, LKML
Hello Peter,
On Sat, 2009-06-06 at 09:53 +0530, Jaswinder Singh Rajput wrote:
> On Fri, 2009-06-05 at 13:55 -0700, H. Peter Anvin wrote:
> > Jaswinder Singh Rajput wrote:
> > > Hello Andrew,
> > >
> > > On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> > >> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> > >>
> > >>> + "ext cpuid level\t: 0x%x\n"
> > >> It's unobvious what "ext" means. External?
> > >>
> > >> Can we make it "extended cpuid level"?
> > >
> > > extended cpuid level will look like this :
> > >
> > > fpu : yes
> > > fpu_exception : yes
> > > cpuid level : 5
> > > wp : yes
> > > extended cpuid level: 0x80000008
> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
> > >
> >
> > The more I'm thinking about this I think it was a mistake to put cpuid
> > level: there in the first place, too. My opinion is increasingly to
> > leave this to x86info or other user-space tools.
> >
>
> cpuid level is as important as cpu family, model and stepping.
>
> For Intel, in some cases cpuid level is more important then cpu family,
> model and stepping. Like you cannot tell by looking at cpu family, model
> and stepping which model is new and which is old like 05_01 or 06_1A or
> 0F_03H ?
>
> But by looking at cpuid level and extended cpuid level you can tell
> which is new and which is old and which supports more features.
>
> So cpuid level and extended cpuid level is better scale than cpu family,
> model and stepping. So I think hiding this valuable information is a
> crime.
>
Highest Value in EAX
Intel 64 or IA-32 Processors Basic Information Extended Function
Information
Earlier Intel486 Processors CPUID Not Implemented CPUID Not Implemented
Later Intel486 Processors and 01H Not Implemented
Pentium Processors
Pentium Pro and Pentium II 02H Not Implemented
Processors, Intel Celeron
Processors
Pentium III Processors 03H Not Implemented
Pentium 4 Processors 02H 80000004H
Intel Xeon Processors 02H 80000004H
Pentium M Processor 02H 80000004H
Pentium 4 Processor 05H 80000008H
supporting Hyper-Threading
Technology
Pentium D Processor (8xx) 05H 80000008H
Pentium D Processor (9xx) 06H 80000008H
Intel Core Duo Processor 0AH 80000008H
Intel Core 2 Duo Processor 0AH 80000008H
Intel Xeon Processor 3000, 0AH 80000008H
5100, 5200, 5300, 5400
Series
Intel Core 2 Duo Processor 0DH 80000008H
8000 Series
Intel Xeon Processor 5200, 0AH 80000008H
5400 Series
Intel Atom Processor 0AH 80000008H
Intel Core i7 Processor 0BH 80000008H
cpuid level and extended cpuid level tells the information about Intel
processor model.
Do you still think it is useless and should not be present
in /proc/cpuinfo .
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-10 16:40 ` Jaswinder Singh Rajput
@ 2009-06-10 17:14 ` H. Peter Anvin
2009-06-10 17:42 ` Borislav Petkov
0 siblings, 1 reply; 18+ messages in thread
From: H. Peter Anvin @ 2009-06-10 17:14 UTC (permalink / raw)
To: Jaswinder Singh Rajput; +Cc: Andrew Morton, Ingo Molnar, x86 maintainers, LKML
>>>>
>>> The more I'm thinking about this I think it was a mistake to put cpuid
>>> level: there in the first place, too. My opinion is increasingly to
>>> leave this to x86info or other user-space tools.
>>>
>> cpuid level is as important as cpu family, model and stepping.
>>
>> For Intel, in some cases cpuid level is more important then cpu family,
>> model and stepping. Like you cannot tell by looking at cpu family, model
>> and stepping which model is new and which is old like 05_01 or 06_1A or
>> 0F_03H ?
>>
>> But by looking at cpuid level and extended cpuid level you can tell
>> which is new and which is old and which supports more features.
>>
>> So cpuid level and extended cpuid level is better scale than cpu family,
>> model and stepping. So I think hiding this valuable information is a
>> crime.
>
> cpuid level and extended cpuid level tells the information about Intel
> processor model. Do you still think it is useless and should not be present
> in /proc/cpuinfo .
>
I think it's pointless, because if you're doing this kind of stuff you
might as well talk to CPUID directly. We have a CPUID interface
already. The kernel isn't meant to replicate x86info or any of those
tools -- it really can't, and at that point why stop at x86info... we
could replicate arbitrary applications at that point.
As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
internally, nevermind display them.
I'm not really all that doctrinal about this, but I'd like to get a
decent answer to the question "where does it stop, *and why*". It's a
slippery slope, and without a target, it goes on forever.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-10 17:14 ` H. Peter Anvin
@ 2009-06-10 17:42 ` Borislav Petkov
2009-06-10 17:48 ` H. Peter Anvin
0 siblings, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2009-06-10 17:42 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jaswinder Singh Rajput, Andrew Morton, Ingo Molnar,
x86 maintainers, LKML
On Wed, Jun 10, 2009 at 10:14:09AM -0700, H. Peter Anvin wrote:
> >>>>
> >>> The more I'm thinking about this I think it was a mistake to put cpuid
> >>> level: there in the first place, too. My opinion is increasingly to
> >>> leave this to x86info or other user-space tools.
> >>>
> >> cpuid level is as important as cpu family, model and stepping.
> >>
> >> For Intel, in some cases cpuid level is more important then cpu family,
> >> model and stepping. Like you cannot tell by looking at cpu family, model
> >> and stepping which model is new and which is old like 05_01 or 06_1A or
> >> 0F_03H ?
> >>
> >> But by looking at cpuid level and extended cpuid level you can tell
> >> which is new and which is old and which supports more features.
> >>
> >> So cpuid level and extended cpuid level is better scale than cpu family,
> >> model and stepping. So I think hiding this valuable information is a
> >> crime.
> >
> > cpuid level and extended cpuid level tells the information about Intel
> > processor model. Do you still think it is useless and should not be present
> > in /proc/cpuinfo .
> >
>
> I think it's pointless, because if you're doing this kind of stuff you
> might as well talk to CPUID directly. We have a CPUID interface
> already. The kernel isn't meant to replicate x86info or any of those
> tools -- it really can't, and at that point why stop at x86info... we
> could replicate arbitrary applications at that point.
>
> As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
> Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
> internally, nevermind display them.
>
> I'm not really all that doctrinal about this, but I'd like to get a
> decent answer to the question "where does it stop, *and why*". It's a
> slippery slope, and without a target, it goes on forever.
I still fail to see a real use case which requires adding that info to
the kernel and querying CPUID directly is _absolutely_ not an option.
This is what the decisive argument should be and not some "but we have
already this and that in there." Otherwise its like painting a broken
car pink - it's still broken.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo
2009-06-10 17:42 ` Borislav Petkov
@ 2009-06-10 17:48 ` H. Peter Anvin
0 siblings, 0 replies; 18+ messages in thread
From: H. Peter Anvin @ 2009-06-10 17:48 UTC (permalink / raw)
To: Borislav Petkov
Cc: Jaswinder Singh Rajput, Andrew Morton, Ingo Molnar,
x86 maintainers, LKML
Borislav Petkov wrote:
>>
>> I'm not really all that doctrinal about this, but I'd like to get a
>> decent answer to the question "where does it stop, *and why*". It's a
>> slippery slope, and without a target, it goes on forever.
>
> I still fail to see a real use case which requires adding that info to
> the kernel and querying CPUID directly is _absolutely_ not an option.
> This is what the decisive argument should be and not some "but we have
> already this and that in there." Otherwise its like painting a broken
> car pink - it's still broken.
>
Exactly, the question is where does it stop *and why* -- give a coherent
argument why drawing a line at any one particular place makes sense.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-06-10 18:45 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-12 7:14 [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for /proc/cpuinfo Jaswinder Singh Rajput
2009-05-12 13:39 ` Borislav Petkov
2009-05-12 13:49 ` Jaswinder Singh Rajput
2009-05-12 14:10 ` Borislav Petkov
2009-05-12 16:40 ` H. Peter Anvin
2009-05-12 18:13 ` Borislav Petkov
2009-05-12 18:47 ` H. Peter Anvin
2009-05-12 19:49 ` Borislav Petkov
2009-06-05 19:20 ` Jaswinder Singh Rajput
2009-05-13 6:21 ` Andrew Morton
2009-05-13 8:03 ` Andi Kleen
2009-06-05 18:38 ` Jaswinder Singh Rajput
2009-06-05 20:55 ` H. Peter Anvin
2009-06-06 4:23 ` Jaswinder Singh Rajput
2009-06-10 16:40 ` Jaswinder Singh Rajput
2009-06-10 17:14 ` H. Peter Anvin
2009-06-10 17:42 ` Borislav Petkov
2009-06-10 17:48 ` H. Peter Anvin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.