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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 April 2011 00:27, Jung-uk Kim <jkim@freebsd.org> wrote: > > That means your VM has broken CPUID support. =C2=A0To get there, it has t= o > meet two conditions, i.e., TSC is invariant and it has APERF/MPERF > MSRs. =C2=A0A simple workaround is setting "machdep.disable_tsc=3D1" > 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikryq%2B%2Bc7%2BwnyhDP=rioWpSiCxABw>