* Mark Kettenis <mark.kette...@xs4all.nl> [2013-01-30 03:49:45]:
> > Date: Tue, 29 Jan 2013 17:35:13 -0500
> > From: Matt Dainty <m...@bodgit-n-scarper.com>
> >
> > * Christian Weisgerber <na...@mips.inka.de> [2013-01-24 13:03:43]:
> > > Matt Dainty <m...@bodgit-n-scarper.com> wrote:
> > >
> > > > --- sys/arch/amd64/amd64/identcpu.c.orig 2013-01-14
> > > > 22:23:43.000000000 +0000
> > > > +++ sys/arch/amd64/amd64/identcpu.c 2013-01-14 22:33:21.000000000
> > > > +0000
> > > > @@ -506,7 +506,8 @@
> > > > if (ci->ci_feature_sefflags & SEFF0EBX_SMAP)
> > > > replacesmap();
> > > > }
> > > > - if (!strncmp(mycpu_model, "Intel", 5)) {
> > > > + if (!strncmp(mycpu_model, "Intel", 5) ||
> > > > + !strncmp(mycpu_model, "Genuine Intel", 13)) {
> > > > u_int32_t cflushsz;
> > > >
> > > > CPUID(0x01, dummy, cflushsz, dummy, dummy);
> > > >
> > >
> > > I think it's dubious that we match the CPU brand name for this at
> > > all. Shouldn't this be properly handled with CPUID?
> >
> > Here's a slightly simpler diff that checks the vendor rather than the
> > CPU brand.
> >
> > I'm not sure if it's safe to check CPUID regardless of vendor, plus
> > there is the CLFLUSH code in that block as well, I figure that's
> > confined to Intel for a reason?
>
> Look at the equivalent i386 code.
It looks like the i386 code ultimately does the same thing, looking
through i386/machdep.c, the CPUID is only checked in
intel686_cpusensors_setup() which is traced back to the big
i386_cpuid_cpus[] struct and intel686_cpu_setup()/intel686_p4_cpu_setup()
which to my eyes only gets called for Intel CPUs.
Matt
