Re: 2.6.14: CR4 not needed to be inspected on the 486 anymore?

[Zachary Amsden <zach@vmware.com>]

linux-os (Dick Johnson) wrote:

> On Mon, 7 Nov 2005, Zachary Amsden wrote:
>
>  
>
> > Maciej W. Rozycki wrote:
> >
> >    
> >
> > > On Mon, 7 Nov 2005, Zachary Amsden wrote:
> > >
> > >
> > >
> > >      
> > >
> > > > While this is at least no worse in the nested fault case than earlier
> > > > kernels, I really wish I had one of those weird 486s so I could test the
> > > > faulting mechanism.  It seems the trap handling code has gotten quite
> > > >
> > > >
> > > >        
> > > What's so weird about 486s?  Besides, for testing it doesn't have to be
> > > one -- you will get away with a 386, too.  I have neither anymore, but
> > > there are people around still using them.
> > >
> > >
> > >      
> > Because I hold in my hand "i486 Microprocessor Programmer's Reference
> > Manual, c 1990", and it has no mention whatsoever of CR4, and all
> > documentation I had until Friday had either no mention of CR4, or
> > something to the effect of "new on Pentium, the CR4 register ..."  So
> > I've had to re-adjust my definition of 486, which was weird.
> >
> > Zach
> > -
> >    
>
> Yes, and undocumented opcodes might not fault. They might do nothing
> or something strange. It's not a good idea to use an undocumented
> opcode in kernel space. The read-from-CR4 in kernel space, hoping
> that an immoral-opcode trap will save you is not good practice.
>
> You might reset the processor.
>  

No, you won't.  #UD and #GP will not (I hesitate to say never, but other 
than a processor bug, I believe that is correct) reset the processor.  
And CR4 is not "undocumented", even on 486.

What is immoral about opcode trapping?

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/