Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Aug 2010 15:36:03 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        Andriy Gapon <avg@icyb.net.ua>
Cc:        jeff@FreeBSD.org, freebsd-stable@FreeBSD.org
Subject:   Re: 8.1-PRERELEASE: CPU packages not detected correctly
Message-ID:  <201008271536.08773.jkim@FreeBSD.org>
In-Reply-To: <4C77F6D6.9020402@icyb.net.ua>
References:  <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008191326.09822.jkim@FreeBSD.org> <4C77F6D6.9020402@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008271536.08773.jkim>