HigherHalfBareBones question?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:HigherHalfBareBones question?

Post 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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Colonel Kernel
Member
Member
Posts: 1437
Joined: Tue Oct 17, 2006 6:06 pm
Location: Vancouver, BC, Canada
Contact:

Re:HigherHalfBareBones question?

Post 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...
Top three reasons why my OS project died:
  1. Too much overtime at work
  2. Got married
  3. My brain got stuck in an infinite loop while trying to design the memory manager
Don't let this happen to you!
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:HigherHalfBareBones question?

Post 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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply