svn commit: r220584 - in head/sys: amd64/amd64 i386/i386

[Garrett Cooper]

On Wed, Apr 13, 2011 at 3:27 PM, Jung-uk Kim <jkim at freebsd.org> wrote:
> On Wednesday 13 April 2011 05:49 pm, Dimitry Andric wrote:
>> On 2011-04-13 23:41, Dimitry Andric wrote:
>> ...
>>
>> > But I don't really see why, yet. :)  With r220532, it worked
>> > fine.
>>
>> Ah, I failed to notice the commit that came before, r220583.
>> Apparently, it can happen (at least in a VM environment) that the
>> DELAY(1000) in this fragment from cpu_est_clockrate():
>>
>>                  wrmsr(MSR_MPERF, 0);
>>                  wrmsr(MSR_APERF, 0);
>>                  tsc1 = rdtsc();
>>                  DELAY(1000);
>>                  mcnt = rdmsr(MSR_MPERF);
>>                  acnt = rdmsr(MSR_APERF);
>>                  tsc2 = rdtsc();
>>                  intr_restore(reg);
>>                  perf = 1000 * acnt / mcnt;
>>
>> will still read 0 from MSR_MPERF, leading to a division by zero.
>> Maybe just fallback to the second method in the 'else' branch then?
>
> That means your VM has broken CPUID support.  To get there, it has to
> meet two conditions, i.e., TSC is invariant and it has APERF/MPERF
> MSRs.  A simple workaround is setting "machdep.disable_tsc=1"
> tuanable from loader but your VM is the real culprit here.

    VMware ESXi lies on multiple fronts in this area I've discovered
lately at $WORK, in particular the SMBIOS / FreeBSD are calling CPUID
which is returning info based on the host processor instead of the
emulated guest processor, which in turn is causes minor problems in
our software. Example being that the host processor is a Intel
Woodcrest CPU (this is what an in-house tool and FreeBSD reports)
instead of a Pentium Pro emulated CPU (that's what dmidecode reports
and that's what ESXi emulates).
    Wasn't happy about this breakage and someone should probably talk
to VMware about fixing their emulation software so that it tells a
consistent story across the board.
Thanks,
-Garrett