Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors

On Wednesday, September 14, 2011 4:02:41 pm Andrew Boyer wrote:
> 
> On Sep 14, 2011, at 3:56 PM, Andriy Gapon wrote:
> 
> > on 14/09/2011 20:59 Andrew Boyer said the following:
> >> When FreeBSD examines the CPU topology using CPUID leaf 11 in
> >> topo_probe_0xb(), it never sets hyperthreading_cpus.  At the end of
> >> topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical.
> >> 
> >> Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to
> >> do the right thing on a system with two quad-core E5620 CPUs.  The APIC IDs
> >> that appear when SMT is enabled in the BIOS get marked AP/HT.
> >> 
> >> Do you agree?
> > 
> > I agree, but...
> > But see this:
> > http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024
> > 
> > Someone long ago has decided that new HTT is not the same as old HTT and that
> > some rules that apply to old HTT should not apply to new HTT.  Even the name.
> > I think that that's not correct.
> > But it doesn't seem that I am able to engage into a discussion the person who
> > made that decision.  Also I can not find any other interested developer either.
> > 
> > Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics.
> > And I don't think that any of my changes affected the dmesg output.
> > 
> > In my "avgBSD" I have different SMP topology code, but it's not ready yet to be
> > submitted for merge into the main tree.
> > 
> > -- 
> > Andriy Gapon
> 
> 
> Actually, it's not useless.  If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, 
since it can't tell which CPUs are actually HTT.

The reason the machdep.hyperthreading_allowed tunable was added was to disable
HTT on Pentium4's due to a security issue Colin found that was specific to the
HTT on Pentium4's.  The second generation HTT is not (AFAIK) subject to the
same vulnerability.  Thus, people disabling HTT because they are paranoid
about RSA keys being sniffed shouldn't end up disabling HTT on newer CPUs
unnecessarily.

In my opinion, though, the old HTT stuff is water way under the bridge at this
point (and I'm a bit skeptical about the practical vulnerability of the old
HTT stuff anyway).

I think the "right" way for an admin to disable HTT is to disable it in the
BIOS so that it doesn't show up in the MADT.  Back when we were doing the
MPTABLE_FORCE_HTT hack having a separate tunable made sense (and it possibly
made some limited sense if you were worried about the vulnerability on running
machines).  However, at this point I think the tunable should just go away and
admins should configure HTT on or off in the BIOS like they would for any
other OS.

-- 
John Baldwin