svn commit: r205307 - head/sys/i386/conf

[Bruce Evans]

On Fri, 19 Mar 2010, John Baldwin wrote:

> On Thursday 18 March 2010 9:16:53 pm Xin LI wrote:
>> Author: delphij
>> Date: Fri Mar 19 01:16:53 2010
>> New Revision: 205307
>> URL: http://svn.freebsd.org/changeset/base/205307
>>
>> Log:
>>   SSE is enabled by default about 5 years ago so there is no point pretending
>>   that we support I486 and I586 CPUs in the GENERIC kernel, users wants these
>>   support would have to build a custom kernel to explicitly disable SSE
>>   anyways.
>>
>>   MFC after:	1 month
>
> No, this is wrong.  Revert this.  We do _not_ unconditionally use SSE in the
> kernel.  GENERIC should run just fine on a 486.  If it doesn't, that should be
> fixed, but I have not seen any reports to the contrary.

Indeed.  This doesn't even break the non-SSE case, since it doesn't
remove I686_CPU or any of the code that dynamically chooses whether
to use SSE.

Most 686's don't have SSE, since a 686 is an old name for a PentiumPro
or maybe a Pentium2 and these don't have SSE (not sure about the
Pentium2, but my old Celeron is Pentimum2-class and it only has FXSR).
However, we keep using this old name for all generations of i386's
after i586, even for generations that are really HAMMERs.  Thus the
static configuration related to I*86_CPU is almost usless: it controls
only couple of options for i486 and i586, with the more complicated
and costly configuration for post-i586 being handled dynamically.
Omitting I486_CPU and I586_CPU thus has very little effect except
breaking i486 and i586, and having these options does little except
support this foot-shooting.  The effect of I486_CPU is especially small.
It is:
- statically disable use of the TSC in the bogus get_cyclecount() API.
   Although the TSC is dynamically configured elsewhere, this function
   wants to use the TSC without any dynamic tests, so it is uses static
   configuration for efficiency.
- avoid compiling in functions to initialize a 486.  There is dynamic
   code to use these functions as needed, but this optimization saves
   a few hundred if not a few thousand bytes.
- panic if the CPU is an i486, since the necessary extra support for
   an i486 (just the above 2 features) is not present.
I586_CPU gives a little more.  E.g., support for fixing the F00F hardware
bug on some Pentium1's.  Again there is dynamic configuration for this
but a few hundred bytes are saved by not compiling it in.

> In general we do not
> use any floating-point / MMX / SSE instructions in the kernel as our FPU
> context-saving code doesn't support it.

Actually, we do, sort of.  We use the fxsave and fxrstor instructions, if
available, in the context-saving code itself.  These are closely related
to SSE, if not part of SSE.  They are in different cpuid flags (FXSR
instead of SSE*), but the dynamic code for using them is configured by
the same ifdefs as for using SSE.  My old Celeron with FXSR thus uses
fxsave/fxrstor but not SSE proper (even in userland).

> All the x86 world is not rack-mounted 64-bit servers.  We should not remove
> support for non-686 CPUs for no good reason.  486 CPUs have cmpxchg and xadd
> so are perfectly adequate.

Why do we still have CPU_DISABLE_CMPXCHG then?  It was mainly for i386, and
is now documented as being useful for old vmware, but hopefully vmware has
been replaced by not-so-old vmware, qemu, kqemu, virtualbox,... and these
support cmpxchg.

The configuration of cmpxchg and a couple of other things is only static.

SSE has both dynamic and static configuration.  Its static configuration
is obfuscated for historical reasons.  It used to be a positive option
but now it is a negative option.  The positive option is set in all 2
files that use SSE (actually only FXSR?) by the following ifdef:

% #if !defined(CPU_DISABLE_SSE) && defined(I686_CPU)
% #define CPU_ENABLE_SSE
% #endif

So CPU_ENABLE_SSE is the default, but the dynamic code for using it can
be not compiled in either by configuring CPU_DISABLE_SSE or by not
configuring I686_CPU.

Bruce