8.1-PRERELEASE: CPU packages not detected correctly

Jung-uk Kim jkim at FreeBSD.org
Fri Aug 27 20:16:15 UTC 2010


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


More information about the freebsd-stable mailing list