From owner-freebsd-current@FreeBSD.ORG Fri Sep 16 12:07:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD7E1065676; Fri, 16 Sep 2011 12:07:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3235E8FC19; Fri, 16 Sep 2011 12:07:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D44E346B49; Fri, 16 Sep 2011 08:07:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 681098A02F; Fri, 16 Sep 2011 08:07:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 16 Sep 2011 08:07:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <2C3C4570-C5F9-42F5-AA81-900151590DB8@averesystems.com> <4E7106DE.40707@FreeBSD.org> <70B018CB-4658-45DD-929E-A953B299E737@averesystems.com> In-Reply-To: <70B018CB-4658-45DD-929E-A953B299E737@averesystems.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109160807.04617.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 16 Sep 2011 08:07:05 -0400 (EDT) Cc: Andriy Gapon , Andrew Boyer Subject: Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 12:07:06 -0000 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