Date: Fri, 27 Aug 2010 16:15:55 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly Message-ID: <201008271615.58056.jkim@FreeBSD.org> In-Reply-To: <4C781640.8010909@icyb.net.ua> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271536.08773.jkim@FreeBSD.org> <4C781640.8010909@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 27 August 2010 03:47 pm, Andriy Gapon wrote: > on 27/08/2010 22:36 Jung-uk Kim said the following: > > 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. > > Thanks a lot for the rest of the info that I snipped, very > interesting and useful! > > To this issue - I'd say let the developers of virtual machines > worry that their machines look like real hardware, not us. > More specifically, in this thread we saw that current FreeBSD code > (without the patch) and Intel's code detect the same topology and > that topology looks reasonable for the person who started the > thread. With the patch though, detected topology looks different. > So I'd rather not worry about the general case of virtual machines > right now. Let's first see more evidence of whether we should trust > them or not. I quickly looked over Xen sources. It seems the CPUID instruction is translated by this code: http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c For HVM case, this is how the CPUID_HTT_CORES is set: 185 case 0x00000001: 186 /* 187 * EBX[23:16] is Maximum Logical Processors Per Package. 188 * Update to reflect vLAPIC_ID = vCPU_ID * 2. 189 */ 190 regs[1] = (regs[1] & 0x0000ffffu) | ((regs[1] & 0x007f0000u) << 1); But CPUID 0x0b is not handled and falls here: 265 default: 266 regs[0] = regs[1] = regs[2] = regs[3] = 0; 267 break; I am not a Xen developer, so please don't shoot me. ;-) Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008271615.58056.jkim>