Page 2 of 2
Re:HigherHalfBareBones question?
Posted: Wed Apr 12, 2006 10:06 pm
by Brendan
Hi,
Colonel Kernel wrote:When the processor loads a page-directory or page-table entry for a global page into a TLB, the entry will remain in the TLB indefinitely. The only ways to deterministically invalidate global page entries are as follows:
- Clear the PGE flag; this will invalidate the TLBs.
- Execute the INVLPG instruction to invalidate individual page-directory or page-table entries in the TLBs.
So, to answer your question, nothing would happen unless you explicitly disabled paging or invalidated the global TLB entry yourself. Otherwise, the address translation for that page will not change.
I would assume that for "the entry will remain in the TLB indefinately", the word
indefinately means "for an undefined amount of time".
Basically, sooner or later the CPU will run out ot TLB entries and it will non-deterministically invalidate your global TLB entries to free some up. It's even more "non-deterministic" than that though...
For example, imagine you've got code like this:
Code: Select all
cli
mov eax,[thePage] ;eax = old data from old TLB
mov ebx,[thePage] ;ebx = old data from old TLB still
mov ecx,[thePage] ;ecx = new data from new TLB
mov edx,[thePage] ;edx = new data from new TLB
sti
If you think this is impossible, have a look at SMM (System Management Mode) - an SMI can occur at any time and can't be blocked. The SMI makes the CPU enter SMM mode (which includes disabling paging) and the BIOS's SMM handler can do anything it likes for as long as it likes. The only way an OS can detect if an SMI was handled is by constantly monitoring the time stamp counter to see if it changes more than it should have.
Cheers,
Brendan
Re:HigherHalfBareBones question?
Posted: Wed Apr 12, 2006 10:18 pm
by Colonel Kernel
Brendan wrote:I would assume that for "the entry will remain in the TLB indefinately", the word indefinately means "for an undefined amount of time".
Basically, sooner or later the CPU will run out ot TLB entries and it will non-deterministically invalidate your global TLB entries to free some up.
Doesn't that defeat at least most of the purpose of marking them "global" in the first place?
Assuming you're right, then the answer to Candamir's question about global pages is -- "nobody knows, so don't do it."
It's even more "non-deterministic" than that though...
For example, imagine you've got code like this:
Code: Select all
cli
mov eax,[thePage] ;eax = old data from old TLB
mov ebx,[thePage] ;ebx = old data from old TLB still
mov ecx,[thePage] ;ecx = new data from new TLB
mov edx,[thePage] ;edx = new data from new TLB
sti
If you think this is impossible, have a look at SMM (System Management Mode) - an SMI can occur at any time and can't be blocked. The SMI makes the CPU enter SMM mode (which includes disabling paging) and the BIOS's SMM handler can do anything it likes for as long as it likes. The only way an OS can detect if an SMI was handled is by constantly monitoring the time stamp counter to see if it changes more than it should have.
That's some scary sh*t. Hopefully the BIOS' SMM handler wouldn't muck around with the OS' page tables or with the TLB...
Re:HigherHalfBareBones question?
Posted: Thu Apr 13, 2006 12:01 am
by Brendan
Hi,
Colonel Kernel wrote:Brendan wrote:I would assume that for "the entry will remain in the TLB indefinately", the word indefinately means "for an undefined amount of time".
Basically, sooner or later the CPU will run out ot TLB entries and it will non-deterministically invalidate your global TLB entries to free some up.
Doesn't that defeat at least most of the purpose of marking them "global" in the first place?
Global pages aren't flushed when CR3 changes so that (if they're re-used) TLB misses are avoided, but the CPU still tries to keep the most useful paging translations in the CPU. Of course "the most useful" is too hard to predict (most CPUs probably have a "least recently used" TLB eviction policy).
Imagine the reverse - a TLB that is entirely full of global entries on a CPU that is trying to run normal (CPL=3 with no global pages) application code. In this case performance would suck because the TLB would be virtually useless, and it would be better for performance to evict the global TLBs so that it can cache something that is actually useful for the work being done.
Colonel Kernel wrote:If you think this is impossible, have a look at SMM (System Management Mode) - an SMI can occur at any time and can't be blocked. The SMI makes the CPU enter SMM mode (which includes disabling paging) and the BIOS's SMM handler can do anything it likes for as long as it likes. The only way an OS can detect if an SMI was handled is by constantly monitoring the time stamp counter to see if it changes more than it should have.
That's some scary sh*t. Hopefully the BIOS' SMM handler wouldn't muck around with the OS' page tables or with the TLB...
The SMM handler shouldn't mess with the state of the OS (CPU registers, memory contents, paging structures, etc) unless it's meant to. An example of this would be SMM code that emulates a PS/2 keyboard or mouse when a USB keyboard or mouse is actually present (i.e. trapping access to the PS/2 I/O ports and changing AL on I/O port reads).
For the TLB, paging is disabled when SMM is entered and re-enabled when the RSM instruction is used. This constitutes a complete TLB flush (including global pages). In addition, the SMM handler may setup it's own paging (and use it's own TLB entries). In general (from the OS's perspective) the contents of all CPU caches are subject to change without notice.
Cheers,
Brendan