Page 2 of 2
Re: Feasibility to keep GDTR and GDT data only into register
Posted: Wed Oct 26, 2016 2:50 am
by Kevin
Brendan wrote:For protected mode only; have interrupt and exception handlers at CPL=3 (e.g. in a shared library maybe). These could do nothing more than call the kernel (via. SYSCALL or SYSENTER) where the kernel still handles the cause of the interrupt or exception.
Don't even interrupt/trap gates within the same privilege level reload the code segment? Actually, you can't even decide whether it's the same privilege level or not without looking at the GDT (except if you use an LDT, but that wouldn't save anything).
Re: Feasibility to keep GDTR and GDT data only into register
Posted: Wed Oct 26, 2016 8:10 pm
by Brendan
Hi,
Kevin wrote:Brendan wrote:For protected mode only; have interrupt and exception handlers at CPL=3 (e.g. in a shared library maybe). These could do nothing more than call the kernel (via. SYSCALL or SYSENTER) where the kernel still handles the cause of the interrupt or exception.
Don't even interrupt/trap gates within the same privilege level reload the code segment? Actually, you can't even decide whether it's the same privilege level or not without looking at the GDT (except if you use an LDT, but that wouldn't save anything).
D'oh - you're right, you would need a single CS descriptor because CPU doesn't do any "if CS field of IDT entry == current CS" optimisation.
Cheers,
Brendan
Re: Feasibility to keep GDTR and GDT data only into register
Posted: Thu Oct 27, 2016 3:58 am
by Kevin
Probably because that would be a similar optimisation as "if cr3 is reloaded with the same value, don't flush the TLB", in other words plain wrong. The GDT could have changed since the shadow registers were initialised from the GDT the last time, so the processor has no choice but to look at it.