Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Jun 2006 21:30:22 GMT
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/98460: [PATCH] fpu_clean_state() cannot be disabled for not AMD processors, those are not vulnerable to FreeBSD-SA-06:14.fpu
Message-ID:  <200606032130.k53LUMPa065352@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/98460; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: Rostislav Krasny <rosti.bsd@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/98460: [PATCH] fpu_clean_state() cannot be disabled for
 not AMD processors, those are not vulnerable to FreeBSD-SA-06:14.fpu
Date: Sun, 4 Jun 2006 07:26:38 +1000 (EST)

 On Sat, 3 Jun 2006, Rostislav Krasny wrote:
 
 >> Description:
 > When FreeBSD is running on any non AMD processor an fpu_clean_state() function
 > adds unneeded operations to a context switch. My patch makes it possible
 > to disable the fpu_clean_state() by rebuilding a kernel with
 > "options CPU_FXSAVE_NO_LEAK".
 >
 > Colin Percival has nothing against my idea in general:
 
 Hrmph.  My review implied that this should be done (not be me :-) before
 committing anything.
 
 The configuration should be dynamic and automatic, so that it doesn't
 take changes to zillions of configuration files to implement and
 document an option that almost no one will know to set.  I think there
 is a simple feature test for the AMD misfeature.  On i386's, this
 should be combined with the cpu_fxsr test so that only a single test
 is needed at runtime.  On amd64's, the test would be 1 unnecessary
 compare-and-branch.  I think it is not useful to have a configuration
 option to avoid this compare-and-branch.
 
 The overhead for fpu_clean_state() is a about 28 cycles.  Has anyone
 actually noticed the extra context switching time for this?  It is
 quite small compared with other overheads.  E.g., the one for using
 the ACPI-[non]fast timecounter was about 2000 cycles at 2GHz.  Even
 this was only noticeable under some loads.
 
 Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606032130.k53LUMPa065352>