From: Zachary Amsden <zach@vmware.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.14: CR4 not needed to be inspected on the 486 anymore?
Date: Mon, 07 Nov 2005 09:32:30 -0800 [thread overview]
Message-ID: <436F8FAE.90805@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0511071157590.27658@chaos.analogic.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
next prev parent reply other threads:[~2005-11-07 17:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-03 16:12 2.6.14: CR4 not needed to be inspected on the 486 anymore? Maciej W. Rozycki
2005-11-03 16:34 ` Zachary Amsden
2005-11-03 17:20 ` Maciej W. Rozycki
2005-11-03 23:49 ` Zachary Amsden
2005-11-05 17:40 ` Andi Kleen
2005-11-07 9:38 ` Maciej W. Rozycki
2005-11-07 15:44 ` Zachary Amsden
2005-11-07 16:37 ` Maciej W. Rozycki
2005-11-07 16:51 ` Zachary Amsden
2005-11-07 17:00 ` linux-os (Dick Johnson)
2005-11-07 17:32 ` Zachary Amsden [this message]
2005-11-07 18:17 ` linux-os (Dick Johnson)
2005-11-07 19:02 ` Ondrej Zary
2005-11-07 17:11 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=436F8FAE.90805@vmware.com \
--to=zach@vmware.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=macro@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.