From owner-svn-src-head@FreeBSD.ORG  Thu Apr 14 15:06:47 2011
Return-Path: <owner-svn-src-head@FreeBSD.ORG>
Delivered-To: svn-src-head@freebsd.org
Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
	by hub.freebsd.org (Postfix) with ESMTP id 67DFB106566B;
	Thu, 14 Apr 2011 15:06:47 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
From: Jung-uk Kim <jkim@FreeBSD.org>
To: Dimitry Andric <dim@freebsd.org>
Date: Thu, 14 Apr 2011 11:06:37 -0400
User-Agent: KMail/1.6.2
References: <201104122349.p3CNn7kK039179@svn.freebsd.org>
	<4DA6D145.8070804@FreeBSD.org>
	<201104141044.55789.jkim@FreeBSD.org>
In-Reply-To: <201104141044.55789.jkim@FreeBSD.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_A2wpNeamMJ/Vg7B"
Message-Id: <201104141106.40303.jkim@FreeBSD.org>
Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org,
	src-committers@freebsd.org
Subject: Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386
X-BeenThere: svn-src-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the src tree for head/-current
	<svn-src-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head>
List-Post: <mailto:svn-src-head@freebsd.org>
List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
	<mailto:svn-src-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 15:06:47 -0000


--Boundary-00=_A2wpNeamMJ/Vg7B
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thursday 14 April 2011 10:44 am, Jung-uk Kim wrote:
> On Thursday 14 April 2011 06:49 am, Dimitry Andric wrote:
> > On 2011-04-14 00:27, Jung-uk Kim wrote:
> > ...
> >
> > >> 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.
> >
> > Well, VM hosts like VMware and VirtualBox usually just return the
> > 'native' CPUID values to guests, but can't really support stuff
> > like those MSRs, for all kinds of reasons.
> >
> > I was just looking at this from a viewpoint of "it worked for
> > years, and now it broke". :)
> >
> > In any case, I don't see why a bit of defensive programming would
> > be bad here, so I propose the following patch to revert to the
> > 'old' way of estimating the rate, in case reading the MPERF MSR
> > returns zero.
>
> I am going to test APERF & MPERF so that you don't need to do that
> from there.  Please stay tuned.

Can you please test the attached patch?

Thanks,

Jung-uk Kim

--Boundary-00=_A2wpNeamMJ/Vg7B
Content-Type: text/plain;
  charset="iso-8859-1";
  name="tsc.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="tsc.diff"

Index: sys/x86/x86/tsc.c
===================================================================
--- sys/x86/x86/tsc.c	(revision 220613)
+++ sys/x86/x86/tsc.c	(working copy)
@@ -183,8 +183,18 @@ probe_tsc_freq(void)
 
 	if (cpu_high >= 6) {
 		do_cpuid(6, regs);
-		if ((regs[2] & CPUID_PERF_STAT) != 0)
-			tsc_perf_stat = 1;
+		if ((regs[2] & CPUID_PERF_STAT) != 0) {
+			/*
+			 * XXX Some emulators expose host CPUID without actual
+			 * support for these MSRs.  We must test whether they
+			 * really work.
+			 */
+			wrmsr(MSR_MPERF, 0);
+			wrmsr(MSR_APERF, 0);
+			DELAY(10);
+			if (rdmsr(MSR_MPERF) > 0 && rdmsr(MSR_APERF) > 0)
+				tsc_perf_stat = 1;
+		}
 	}
 
 	if (tsc_skip_calibration) {

--Boundary-00=_A2wpNeamMJ/Vg7B--