Alternative multitasking method; which is faster

[earlz]

Well i was thinking about possible ways to completely skip the TSS as not do a single thing with it. And well have figured out a way.
Use the timer irq and because when you go to the irq it is ring 0 so just switch some stuff such as stack and return address/segment and iret. but would this way be faster than TSS, to me it would be much easier to implement

[Candy]

Well i was thinking about possible ways to completely skip the TSS as not do a single thing with it. And well have figured out a way.
Use the timer irq and because when you go to the irq it is ring 0 so just switch some stuff such as stack and return address/segment and iret. but would this way be faster than TSS, to me it would be much easier to implement

That's pretty common, since most newer processors (64-bit mode) don't support TSSes anymore in the traditional sense of per-task entry for task switching. It's called software task switching and it should give you numerous hints if you search on it.

[Pype.Clicker]

true. including recent posts (one or two weeks ago).

btw, you cannot _completely_ avoid TSS: you need them for ESP0/SS0 information and if you plan to support multi-processor systems, you _at least_ need one TSS per CPU (because each CPU runs a different thread with a different needs for ESP0/SS0).

[earlz]

yea that would make sense. but i'm not supporting multi cpu

[dh]

@Pype: Wouldn't that mean that the x86-64 chips can't do SMP multitasking :O. You said that you can't avoid TSS altogether, but earlier, somebody stated that 64bit chips don't support it any longer. This is just a paradox by the looks of it .

[Brendan]

Hi,

@Pype: Wouldn't that mean that the x86-64 chips can't do SMP multitasking :O. You said that you can't avoid TSS altogether, but earlier, somebody stated that 64bit chips don't support it any longer. This is just a paradox by the looks of it .

First, don't confuse "64 bit chips" with "64 bit chips running in long mode" - for a 64 bit chip that is not running in long mode everything is the same as a 32 bit chip.

For long mode hardware task switching is not supported, but there's still at least one TSS.

In long mode the TSS uses a different format, and contains values for ESP0, ESP1 and ESP2, an "interrupt stack table", and a I/O permission bitmap. The I/O permission bitmap is the same as a 32 bit TSS. The ESP0 to ESP2 fields are used just like the SS0:ESP0 to SS2:ESP2 fields in a 32 bit TSS for privilege level changes.

The interrupt stack table (or IST) is a completely new thing, which allows different interrupts to have their own "interrupt specific" stack. The idea here is that for something like a double fault handler the kernel stack may be unusable. In a 32 bit system you'd use a hardware task switch to change to a reliable kernel stack and avoid a triple fault, while in long mode you can't - you'd use the IST to assign a "known good" stack to the double fault handler instead.

In long mode, an OS can use one TSS for all tasks and adjust the contents of that TSS during a task switch, could use one TSS per task and do LTR during the task switch, or could mix both of those methods (e.g. one TSS shared by all normal tasks and one TSS per device driver to avoid copying I/O permission bitmaps around).

This means that Pype's comment was mostly correct for both protected mode and long mode - in both cases you may need at least one TSS per CPU.

There is one method to avoid this though - you can use paging where there's a different physical page for each kernel stack mapped at the same linear address. In this case you can use the same TSS for all CPUs (for both protected mode and long mode).

This still means that you must have at least one TSS if you allow privilege level changes. The only way this can be avoided is by running all code at CPL=0 (and not using the IST in long mode).

Therefore, an OS that completely avoids using any TSS is technically possible, but you'd have no protection. I can think of 3 ways this can work - an OS without any protection at all (perhaps a games OS or something designed for embedded systems), use managed code (e.g. Singularity), or run code in virtual machines.


Cheers,

Brendan

[dh]

@Brenden: Ahhh. Thanks, that makes it a WHOLE lot clearer. I have little knowledge of the 64-bit archectures at the moment, because I have no reason to develop for them (don't have the hardware to test on).

Cheers, DH.

[Pype.Clicker]

There is one method to avoid this though - you can use paging where there's a different physical page for each kernel stack mapped at the same linear address. In this case you can use the same TSS for all CPUs (for both protected mode and long mode).

either i'm now confused here, or this implies that you cannot have two threads of the same process running at the same time on different CPUs, right ?

i mean, if all CPUs use the same TSS 'X' and you have two threads from the same process (thus sharing the _same_ address space, same page directory, etc) up at a given time, then those two CPUs are using the same kernel stack pointer ... which may lead to troubles...

... or have you assumed that they were bcos threads with that "as much private state per thread as possible" ?

[Brendan]

Hi,

either i'm now confused here, or this implies that you cannot have two threads of the same process running at the same time on different CPUs, right ?

i mean, if all CPUs use the same TSS 'X' and you have two threads from the same process (thus sharing the _same_ address space, same page directory, etc) up at a given time, then those two CPUs are using the same kernel stack pointer ... which may lead to troubles...

... or have you assumed that they were bcos threads with that "as much private state per thread as possible" ?

You're correct - you would either need to ensure that threads belonging to the same process are not run on different CPUs, or use a different address space for each thread.

For people like Jordan3 who don't intend to support multi-CPU, or for people who's kernel doesn't support multi-threading (e.g. threads implemented as a user level library) or for people like me (an address space per thread) it would work without problems... ::)


Cheers,

Brendan

[JAAman]

i intend to use a hybred option:

threads use the same page tables (no reload on task switch), but certain pages are changed (some of the page tables are modified) -- this includes the current stack (at least kernel -- haven't desided about user stack yet) and a couple other structures (my task structure must be changed for each thread -- its always located at a fixed memory address -- just change the page, and you switch structures)

[dh]

Somebody should take a gun to Intel, and tell them to TOTALLY REDO THE ARCHECTURE! Processor, bus design, EVERYTHING. Then the world can sit back as non-paradoxial documentation is printed out . That or we can all move to the new Intel-Macs .

I really wish that intel left in support for Hardware TSS. If so, things may just have been a *tad* more easier on developers.

Cheers, DH.

[Kemp]

Yes, that would be easier on a few people (ie, pretty much only us who can't afford to find out what really goes on in the hardware), but would be suicide for Intel as it would eliminate all upgrade paths for existing users plus would mean that the cycle of designing every piece of hardware and software for people to use would have to start from scratch, and people would have to completely replace all the hardware/software they own when they want to move up. You're not allowed backward-compatibility as that would re-introduce annoying "features" (think of the trouble the A20 gate caused).

[Brendan]

Hi,

Somebody should take a gun to Intel, and tell them to TOTALLY REDO THE ARCHECTURE! Processor, bus design, EVERYTHING.

Intel did - it's called Itanium...

I really wish that intel left in support for Hardware TSS. If so, things may just have been a *tad* more easier on developers.

AFAIK it was AMD that took hardware task switching out, not Intel.

To be honest, the problem isn't that hardware task switching was taken out, it's that hardware task switching was put in to start with. The 80386 should have had one register to tell the CPU where the page directory is (CR3), one register to tell the CPU where the I/O permission bitmap is (CR5?) and a pair of registers for each privilige level stack (SS0:ESP0, SS1:ESP1, SS2:ESP2).


Cheers,

Brendan

[srg]

AFAIK it was AMD that took hardware task switching out, not Intel.

To be honest, the problem isn't that hardware task switching was taken out, it's that hardware task switching was put in to start with. The 80386 should have had one register to tell the CPU where the page directory is (CR3), one register to tell the CPU where the I/O permission bitmap is (CR5?) and a pair of registers for each privilige level stack (SS0:ESP0, SS1:ESP1, SS2:ESP2).

It was AMD taht took out the hardware task switching, AFAIK because it's unwanted baggage that no-one ever uses.

[JoeKayzA]

It was AMD taht took out the hardware task switching, AFAIK because it's unwanted baggage that no-one ever uses.

In fact there are not many people who use it, and amd provided an alternative to the task gate in the idt with its interrupt stack table. But it's still funny to see that you still need a single TSS for full operation ... this is one of the reasons why I start to doubt that amd64 is really such a cleaner and more comfortable architecture than x86 was - it's still carrying around a lot of baggage IMO.

cheers Joe