Date: Thu, 14 Apr 2011 12:26:30 +0200 From: Ivan Voras <ivoras@freebsd.org> To: Jung-uk Kim <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 Message-ID: <BANLkTikryq%2B%2Bc7%2BwnyhDP=rioWpSiCxABw@mail.gmail.com> In-Reply-To: <201104131827.39373.jkim@FreeBSD.org> References: <201104122349.p3CNn7kK039179@svn.freebsd.org> <4DA6189A.5040200@FreeBSD.org> <4DA61A70.8040609@FreeBSD.org> <201104131827.39373.jkim@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
On 14 April 2011 00:27, Jung-uk Kim <jkim@freebsd.org> wrote: > > 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. You are probably right but fixing VMs is not going to happen (or not soon enough) so workarounds must be implemented. I don't know if it is called early enough for this purpose, but detect_virtual() in kern/subr_param.c initializes the vm_guest variable which could be useful for such workarounds (also see how vm_guest is used in init_param1() in the same file to scale down HZ).home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikryq%2B%2Bc7%2BwnyhDP=rioWpSiCxABw>