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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"