Bug #400
closed
Intel CPUID2 (data in ecx after cpuid) patch
0%
Description
Attached patch adds detection, storage and printing of additional flags
reported by cpuid in the ecx register on newer Intel CPUs. One problem I
have, is that cpu_feature (and the new cpu_feature2) are declared in
sys/systm.h, when they're actually machine dependent. Shouldn't they
rather be in e.g. machine/cpufunc.h?
The printing stuff was obtained from FreeBSD, as for the CPUID2 constants.
Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net
Files
Updated by qhwt+dfly over 17 years ago
You can rip this `#ifndef CPUID2_EST' part completely, because CPU
feature bits won't change after the machine booted. The code was
only there because I didn't want to mess with identcpu.c :)
Updated by TGEN over 17 years ago
Will do. What do you think about the <sys/systm.h> containing MD
definitions?
Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net
Updated by qhwt+dfly over 17 years ago
It's been moved from <machine/md_var.h> by this commit:
http://leaf.dragonflybsd.org/mailarchive/commits/2006-11/msg00027.html
The current users of cpu_feature outside /sys/{cpu,machine} are:
emulation/linux/i386/linprocfs/linprocfs_misc.c
kern/kern_ktr.c
net/altq/altq_subr.c
the last two files use it to deal with TSC register, which is also
specific to CPU. I guess that this is the reason cpu_feature has been
moved into <sys/systm.h> (but you should ask Matt, of course).
It looks OK to me to move it into cpufunc.h; my only question is
what the name(s) of CPU name is for vkernel, if we're to move to
<machine/cpufunc.h>.
Cheers.
Updated by TGEN over 17 years ago
Hmm. Imho, it should remain under machine/, perhaps with an include in
sys/systm.h.
You mean MI code has special handling of the x86 TSC? There ought to be
a better way...
I'm not yet positive of where it really should end up, none of the
cpu*.h files, nor specialreg.h seem entirely appropriate. But I'll
commit the original patch with the removing of the logic in est.c in 24
hours, leaving this for another time.
Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net