Re: A few low-level GDT/LDT K64 questions
Re: A few low-level GDT/LDT K64 questions
- Subject: Re: A few low-level GDT/LDT K64 questions
- From: William Kucharski <email@hidden>
- Date: Thu, 17 Sep 2009 11:06:02 -0600
Actually, most of your questions are IA32e architecture rather than kernel
questions per se, so aside from Apple chiming in with any Mac OS X-specific details:
1. Is there an expectation within the kernel that the in-memory
descriptor tables will be synchronized with the descriptor cache?
That is, if the GDT or LDT is modified, can the descriptor cache
hold stale values (beyond the local scope of the GDT/LDT
modification)?
Of course it CAN; until the referencing segment registers are reloaded, the
cache can be stale with respect to the GDT/LDT.
This becomes even more entertaining in long mode because the descriptor cache
for FS and GS are always "stale" with respect to the GDT/LDT if the MSRs have
been used to set a 64-bit base value.
Therefore one needs to be careful when porting code over from 32-bit mode that
does a mov or pop to %fs or %gs as in long mode they'll leave the descriptor
cache loaded with the 32-bit base value from the GDT/LDT, which in most cases is
NOT likely to be the value you want.
3. In general, can the following sequence expected to be idempotent
with respect to the %fs descriptor cache:
mov $IA32_FS_BASE, ìx
rdmsr
mov %fs, %bx
mov %bx, %fs
wrmsr
As long as you're in long mode, once the wrmsr has completed, yes.
I didn't answer question (2) because in theory, yes the GDT or LDT could be
modified so that existing selector indices are beyond the bounds of the
descriptor table in question, but I'm unaware as to whether whatever routines
Mac OS X has for manipulation of them enforces the validity of segment register
indices.
William Kucharski
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden