site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 2.0.0.23 (X11/20090910) 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)? 3. In general, can the following sequence expected to be idempotent with respect to the %fs descriptor cache: mov $IA32_FS_BASE, %ecx rdmsr mov %fs, %bx mov %bx, %fs wrmsr As long as you're in long mode, once the wrmsr has completed, yes. William Kucharski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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: 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. 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. This email sent to site_archiver@lists.apple.com