From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 19:36:18 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1B9741065675; Fri, 27 Aug 2010 19:36:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 15:36:03 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008191326.09822.jkim@FreeBSD.org> <4C77F6D6.9020402@icyb.net.ua> In-Reply-To: <4C77F6D6.9020402@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271536.08773.jkim@FreeBSD.org> Cc: jeff@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:36:18 -0000 On Friday 27 August 2010 01:33 pm, Andriy Gapon wrote: > on 19/08/2010 20:26 Jung-uk Kim said the following: > > One thing I am not sure is whether those CPUID instructions are > > executed on *real* CPUs or translated in HVM. On top of that, I > > am not even sure they will be executed on *correct* cores. I bet > > they won't. > > Hmm, I have an impression that we try to detect the topology by > doing stuff only on BSP and that's why we handle properly only > uniform topologies. So that would make your point about correct > cores moot. > Am I mistaken? No, you're correct. Here goes little background information. Originally, Jeff tried to implement Intel's algorithm[1] as described here, if my understanding is correct: http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ Unfortunately, this algorithm needed to execute CPUID instruction on every core and aggregate them later. Thus, he had to compromise and made it simpler, I believe[2]. However, this compromise had some side effects and my patch was an attempt to correct them (sorry, I forgot the details). It was never committed because Jeff said "I will look it over in more detail soon" at the time. Then, I had to return the CPU, which was an engineering sample[3] and now in production. That's how my patch has been neglected for long time and just re-discovered from trashcan of rejected patches, thanks to this thread. ;-) Now, back to my original question. My point was, we should never trust any CPUIDs on emulated CPU if they are translated. What should happen if you have four physical cores and you "assign" just one for VirtualBox, for example? What should we "announce" if you are emulating two cores on UP host? How do we know whether it is "the" real BSP or not? Is it really bound to a CPU? Is "CPUID leaf 11" emulated properly? If not, is it an emulator bug or a guest OS bug? Do we really care about "physical topology" in these cases? IMHO, the answer is no, we don't, and we should say "all cores are independent". If anyone really cares and wants prettier printing, we may say "N virtual cores", though. I hope it makes sense. Jung-uk Kim [1] I believe he referenced an older revision, though. [2] It was committed as r191648: http://svn.freebsd.org/viewvc/base?view=revision&revision=191648 Also, this commit is related to kern/145385: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my patch won't work on them. If anyone has a Bulldozer sample, please look into it.