Bochs freaks out on TSS

[Candy]

Been working on this for about 10 hours now... bochs claims the TSS descriptor doesn't point to a valid TSS. The descriptor (hexdump)

6B 00 80 36
03 89 00 00

which in my opinion evaluates to hex addr 0x33680 , limit 0x6B type 32-bit free TSS . The contents of address 210560 (which equals 0x33680) is (hexdump) :

00 00 00 00
00 00 00 00
10 00 00 00
00 00 00 00
10 00 00 00
00 00 00 00
10 00 00 00
00 00 00 00
83 00 02 00
02 02 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
10 00 00 00
08 00 00 00
10 00 00 00
10 00 00 00
10 00 00 00
10 00 00 00
20 00 00 00
00 00 68 00

in which I cannot see anything incorrect.

The backlink from the current TSS (loaded with LTR) points to this descriptor, GDT, CPL 0.

What am I doing wrong?

[Pype.Clicker]

hmmm ... wait. You mean you're jumping to your current TSS ?? you can't do that ... or did i misunderstand

The backlink from the current TSS (loaded with LTR) points to this descriptor, GDT, CPL 0.

[Candy]

no, in total I have 3 TSS'es, 3 descriptors (goes with the TSS'es), and (for convenience, the bootup routine has TSS 32, the idle task has TSS 0 and the main routine to be started is TSS1, this was hexdump of TSS 1) TSS 32 points to the descriptor for TSS1. TSS1 is free, TSS32 is in use (LTR). I've set the NT bit in eflags, and am doing an IRET. This would invoke a task switch (if I'm right).

[mystran]

If I'm not mistaken, if you are using the back-link, the TSS you are returning to, should be busy.

[Candy]

*slaps head* so true...

Thanks for pointing that out, it'd have taken me days.

Since this would defeat the purpose of hw task switching I've decided to start doing sw task switching. Now, I've got the code so far that a task starts, but the PIC doesn't pass any interrupts after the first one. I'm not finishing the interrupt sequence with an iret, but I am doing a stack switch. What does the CPU need from an iret that I cannot do? I have enabled AEOI on the PIC, and am also sending a manual end of interrupt, yet I do not get another interrupt. What part of the docs am I missing here?

[Pype.Clicker]

are you sure you send the EOI clearance *before* any task switch occur ??

[Ozguxxx]

I am not sure it this is your problem but interrupts are disabled when they are handled through an interrupt gate. iret pops eflgs from stack so somehow your ints might be disabled by some changed eflags inside isr0. Also I want to ask sth:

Since this would defeat the purpose of hw task switching I've decided to start doing sw task switching.

What do you mean by this? Why is purpose of hw task switching defeated?

[Candy]

I am not sure it this is your problem but interrupts are disabled when they are handled through an interrupt gate. iret pops eflgs from stack so somehow your ints might be disabled by some changed eflags inside isr0. Also I want to ask sth:

Since this would defeat the purpose of hw task switching I've decided to start doing sw task switching.

What do you mean by this? Why is purpose of hw task switching defeated?

The first part probably answers the question yep...

Well... since I was trying to do hw task switching by using iret/NT=1 to change to a new task, and a hw interrupt to get back, using hw task switching would not allow me to protect programs that were in use. Not having that would not work, so it'd defeat the purpose. And beside, porting to AMD64 later on would be harder.

[Ozguxxx]

Well, first of all creating nested tasks is not only way to do hw task switching, you can also set valid tsses, tss descriptors inside gdt, and do just as: JMP tss_desc:0 (dont do CALL then cpu links task and you have to return with an iret) to do task a switch. In fact (I think) task linking is not really necessary, you can do all things with just jumping, but not calling. I think linking tasks are complicating matters but they might have some I dont know maybe protection abilities if crafted properly, but currently -me, as being an hw task switching one- I dont think about linked tasks...

And beside, porting to AMD64 later on would be harder.

Well, most people implement both hw and sw switching together to get final process managing done. In fact my main enthusiasm to choose this opposite direction to other people by choosing hw task switching is that I somehow thought that I can more easily adapt sw task switching to my design later after hw task switching... Also I could nto understand how hw did not let you from protecting a program in memory...

[Candy]

And beside, porting to AMD64 later on would be harder.

Well, most people implement both hw and sw switching together to get final process managing done. In fact my main enthusiasm to choose this opposite direction to other people by choosing hw task switching is that I somehow thought that I can more easily adapt sw task switching to my design later after hw task switching... Also I could nto understand how hw did not let you from protecting a program in memory...

Going from hw to sw is easier indeed, but... since AMD64 does not have hw task switching, does not have segmentation (you must use flat mode...) I'm not implementing those things since I'll be forced to remove / rewrite them when I do transfer.

Still, if you don't need hw task switching and it would only be a pain later on, why do it?

And for the last point, I couldn't implement HW task switching in my way, and switching to sw was going to happen anyway, it just needed a little reason (if only to be able to keep working). PS: it's working now.