Re: Slightly off-topic: a question on the Pentium arc hitecture

I actually mean the GDT. Let me give you some background. I’m trying to
figure out if it is possible to context-switch in a Pentium by (1) saving
registers, (2) frigging CR3, (3) restoring registers, (4) return to caller.
This would mean that every process has its own GDT precisely at the same
linear address (and possibly its own TSS, also at the same GDT offset), so
that changing CR3 would flip the virtual to physical memory mapping
underneath the segment registers but not the virtual addresses themselves.
This is for my OS class at college. The feasibility of the scheme hinges on
how the segment register cache works, and that’s not very well documented in
the P4 books.

So, the question is, can I switch GDTs under the CS/DS/SS’s very nose by
just changing CR3, and not bothering to save and restore the segment
registers ?

Alberto.

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, January 14, 2003 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium
architecture

Alberto,
I can’t imagine what you ar doing that requires this (writing your own
kernel?) and I’m terribly out of date but since no-one else has commented…
CR3 is the task’s PDBR. It’s normally loaded on a task switch - indeed
my Pentium manual excludes mov cr3,xxx from the list of operations.
(You can only move to CR0, CR2, CR4, or from any of CR0 1 2 3 4.)
Also I think you mean the task’s LDT not GDT…
IMHO exploring the dusty corners of the CPU like this, instead of task
switching in the way Intel intended, is a recipe for finding obscure
bugs in the CPU. Certainly if you do something that is not documented
it may not work on all the CPUs. Don’t forget to allow for AMD & Cyrix!
The PIII manual says
“These instructions have the following side effects:
? When writing to control register CR3, all non-global TLB entries are
flushed. Refer to Section 3.7., Translation Lookaside Buffers (TLBs) in
Chapter 3, Protected-Mode Memory Management of the Intel Architecture
Software Developer?s Manual, Volume 3, for a detailed description of the
flags and fields in the control registers.”
which seems to mean you are in the clear on the PIII. I don’t have the
position on the PII, and I’d guess the PIV does the same. The specs are
IAC downloadable at
http://developer.intel.com/design/Pentium4/manuals/
http://developer.intel.com/design/PentiumIII/manuals/
http://developer.intel.com/design/PentiumII/manuals/
http://developer.intel.com/design/Pentium/manuals/
http://developer.intel.com/design/celeron/manuals/

then there’s another set on the AMD site…

Hope this helps a little.

Andy

Moreira, Alberto wrote:

This is a trifle off-topic, but maybe some of you guys have an answer.
Assume each process has its own GDT with say, three entries: a code
segment at position 1, a data segment at position 2 and a tss at
position 3. Assume that I switch from process A to process B by writing
CR3.

If I use a sequence like

mov cr3,eax

mov eax,[ds+blah]

I take that the base address for ds is taken from the ds register
cache and not from the new GDT ? Or is the architecture intelligent
enough to reload the cache on the fly from the descriptor in the new GDT
? Furthermore, if I intersperse a ds load, such as

mov cr3,eax
mov eax,2;
mov ds,eax
mov eax,[ds+blah]

Does the ds register cache get reloaded, or is the processor too
intelligent for its own good, and assumes that because the selector
being loaded is the same as before, there’s no need to reload ?

Thanks if anyone can shed any light !

Alberto.

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.