Date: Wed, 13 Apr 2011 19:07:33 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric <dim@freebsd.org> Subject: Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386 Message-ID: <201104131907.35216.jkim@FreeBSD.org> In-Reply-To: <BANLkTinOV60xH_iXMAnE-oQ9P=P67d4-%2BQ@mail.gmail.com> References: <201104122349.p3CNn7kK039179@svn.freebsd.org> <201104131827.39373.jkim@FreeBSD.org> <BANLkTinOV60xH_iXMAnE-oQ9P=P67d4-%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 13 April 2011 06:33 pm, Garrett Cooper wrote: > On Wed, Apr 13, 2011 at 3:27 PM, Jung-uk Kim <jkim@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. Yeah, it is really shame that VMware (and others) suck in this area. VMware just exposes nominal frequency of the host CPU (or user can configure it) and advertises it is constant. Then, RDTSC instruction is trapped and scaled at the fixed frequency. On the other hand, VirtualBox has a different problem, e.g., TSC does not scale properly. I think it just detects the *current* frequency of the host CPU and never changes even if host clock frequency changes. I believe you can just disable TSC in VM guest and use other clock sources until they fix the problems. AFAIK, virtualized TSC has no benefit over other clock sources, unlike real hardware anyway. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104131907.35216.jkim>