genuine cpu I386_CPU kernel support

[Nate Eldredge]

On Wed, 23 Sep 2009, John Baldwin wrote:

> On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote:
>> John Baldwin wrote:
>>> Other things added since then assume at least a 486.  Not having cmpxchg is a
>>> bit of a killer.
>>
>> I think a 386 can assume non-SMP in which case that can be simulated
>> just fine :-)
>>   it also simplifies a lot of the other breakages..
>>
>> #if (CPU == 80386) && defined(SMP)
>> #error "can't have smp on a 386"
>> #endif
>
> No, it actually does not.  The in-kernel version of cmpset for 386 was to
> disable interrupts while doing a cmp and jmp around a mov (even 386's have
> preemption, so you do have to disable interrupts).  You can't do that in
> userland (cli is a privileged instruction), which probably mandates doing a
> cmpxchg emulator in the kernel for userland code.  That and disabling
> interrupts is actually far less efficient than spl() for a UP 80386 machine.
> I suspect newer kernels will run slower on an 80386 than 4.x.

Another issue that I know affected Linux is that the 386 would allow 
kernel code (CPL 0) to write to a page that was marked read-only.  The 486 
and later would generate a page fault.  Linux takes advantage of the 486 
behavior to avoid having to do explicit access checks when copying to user 
space, though AFAIK it checks the CPU at boot time to decide if this can 
be done.  I haven't checked whether FreeBSD uses this feature, but it 
would be another thing to watch out for.

-- 

Nate Eldredge
nate at thatsmathematics.com