OSDev.org

My OS uses legacy mode only for now, and not long mode if supported. I don't really make use of task gates but was considering implementing a few within my IDT, and I have a few questions that the processor manuals are a little vague on.

-Since this vector isn't low enough to be an exception, nor is it used by any of my IOAPIC's, invocation can only occur via INTn.

-Once I task switch to this TSS I understand that my previous task link selector and registers are saved and ready to be restored when it returns with eflags.nt set and IRET.

-The question is, when I IRET with the NT flag set, is the task gate TSS data saved? So technically a subsequent INTn to the same task gate would resume after the IRET occured?

I suppose I could put an instruction after the IRET which sort of 'resets' and jumps back to the beginning of the function. Or is the task not saved in this case?

Thanks

Hi,

doxrobot wrote:I suppose I could put an instruction after the IRET which sort of 'resets' and jumps back to the beginning of the function.

Yes. You'd need to do something like:
Using hardware task switching for some sort of system call makes it harder to access any parameters passed by the caller or return anything back to the caller (especially if there's data on the caller's stack or in the caller's address space); causes serious performance problems (partly due to changing CR3 and trashing TLB entries); is not re-entrant which means that it's tricky to do anything involving scheduling (e.g. "sleep()" or "read()" or anything else that causes the task to block) and impossible to handle multi-CPU (without having an IDT and TSS for each separate CPU); and has no advantages over using a much simpler/faster "interrupt gate" or "trap gate".

For using hardware task switches for exception handlers you have the same problems. This is why it's normally only used for the double fault exception handler (in the hope that if the kernel has trashed itself the CPU can still switch to the double fault exception handler's task) but even that is dubious at best (if the kernel has trashed itself there's no guarantee that it hasn't trashed the IDT, the double fault exception handler's TSS, etc) and it's better to ensure that the kernel doesn't trash itself to begin with.

Also note that (above) I'm only talking about using the hardware task switch for increased security/protection (and I'm not talking about using it for switching between actual tasks). To use hardware task switches for switching between actual tasks the scheduler uses a "JMP far" for the task switch to ensure that the backlink and NT flag aren't set. Of course this is known to be slow and pointless too (as almost everything the CPU does as part of a hardware task switch is unnecessary in this case).


Cheers,

Brendan

cool, thank you for your input again. In the end I'm sure I wont find any real use for them, I was just trying something new ;p

As for clock cycles the actual switch is insanely slow compared to either a simple INTn or syscall/sysenter for system calls so yeh

thanks Brendan