If you are in 64-bit and have a gdt with the null segment, the kernel code segment, and the kernel data segment, and you load in two new segments in after the three (one for user-mode code and user-mode data) I have to redo lgdt with a new gdtr that has a longer limit that includes the two new segments and then I'd have to flush the GDT wouldn't I?
And then I'd have to flush it but as I don't have the ability to do a far jump like "jmp 0x08:.flush" I'd have to do something like an iretq trick wouldn't I?
GDT reloading question
Re: GDT reloading question
Hi,
This means that if you have a GDT with 5 entries (null, code, data, not present, not present) and the GDT limit is 5, and you change both of the "not present" entries to something else; then you haven't changed the GDT address or the GDT limit and don't have to do LGDT at all. However, if you have a GDT with 3 entries and you increase the limit to make room for 2 more entries, then you would need to do LGDT to tell the CPU that the GDT limit changed.
When you load a segment register and the new descriptor is identical to the old descriptor, then there's no point loading the segment register. This means that (for example), if you move the GDT to a different address and change the GDT limit (and do LGDT so the CPU knows), but you don't change the contents of any of the descriptors that are currently loaded into any segment registers, then there's no point reloading segment registers.
Cheers,
Brendan
The CPU only keeps track of the GDT address and the GDT limit (it doesn't have a special cache for descriptors or anything). If you change the address of the GDT then you have to do LGDT so the CPU knows, and if you change the limit of the GDT then you have to do LGDT so the CPU knows.lackerty wrote:If you are in 64-bit and have a gdt with the null segment, the kernel code segment, and the kernel data segment, and you load in two new segments in after the three (one for user-mode code and user-mode data) I have to redo lgdt with a new gdtr that has a longer limit that includes the two new segments and then I'd have to flush the GDT wouldn't I?
This means that if you have a GDT with 5 entries (null, code, data, not present, not present) and the GDT limit is 5, and you change both of the "not present" entries to something else; then you haven't changed the GDT address or the GDT limit and don't have to do LGDT at all. However, if you have a GDT with 3 entries and you increase the limit to make room for 2 more entries, then you would need to do LGDT to tell the CPU that the GDT limit changed.
When you load a segment register and the new descriptor is identical to the old descriptor, then there's no point loading the segment register. This means that (for example), if you move the GDT to a different address and change the GDT limit (and do LGDT so the CPU knows), but you don't change the contents of any of the descriptors that are currently loaded into any segment registers, then there's no point reloading segment registers.
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.
Re: GDT reloading question
Okay, thanks. That is what I was hoping for as the manual says that it stores the descriptor contents in hidden registers for each Segment Register but I wasn't sure.
Thanks again for the help.
Thanks again for the help.