TSS w/ IOMAP switch using CR3

[Kevin McGuire]

I am curious, if it is possible to switch the IOMAP in a TSS struct by using linear mapping. Or, does the processor ignore linear mapping, and use physical mapping to access the TSS?

I wanted to create a TSS, at a address like this:

TSS = (0xA000 - sizeof(TSS))
So the last byte before the IOMAP resides at 0xAFFF.
Then map a private IOMAP for each process to:
IOMAP = 0xB000

On process switches the CR3 is changed, thus a new IOMAP is loaded if the processor uses linear mapping to access the TSS, or not, will it still work?

Or, does the IOMAP get cached? Can this cache get updated?
[edit]
I just read that the processor invalidates the cache when CR3 is loaded. But, I still do not know if this would work?

[Pype.Clicker]

afaik, you _can_ split the data of a TSS among different pages.

What you *cannot* have is the first 0x68 bytes split on two pages and one of those pages not being there when the first one is there (iirc). I'm unsure about whether the two pages should be physically contiguous or not, however. the manual should tell.

[Kevin McGuire]

kmcguire wishs the manuel did.. Thanks pype.

I am going to try it, but if anyone does know if it is possible or not I would love to hear!

[kataklinger]

Manual says that if TSS splits in two pages, both pages must be present, so this looks like that CPU use linear address not physical.

[Phugoid]

My manual says that the first 0x68 bytes of the TSS have to be in a contiguous physical region:

During a task switch, the processor reads and writes into the first 104 bytes of each TSS (using contiguous physical addresses beginning with the physical address of the first byte of the TSS).

In fact it implies that only the page containing the first byte of the TSS must actually be present. I would not rely on that, even if it works for some processors, though.

[Pype.Clicker]

the base of a TSS is like the base of any other segment. it gives you an address that won't go through the GDT anymore but that still have to go through paging mechanisms.

(not 100% sure that's what Intel calls "linear address")

So the pages containing the TSS (and the IOMAP) are like all data pages for the L1 or L2 data caches (which work on physical addresses) and their page entries are cached by the Translation Lookaside Buffer such as any other page entries.

If you wish to have the TSS's bitmap changing with CR3 switches, just using "regular" page would do the trick, while you may prefer a "global" page for the "fixed" part of the TSS (so that it remains the same for every space and doesn't suffer from TLB flush due to CR3 reloading)

[Kevin McGuire]

@Pype, Phugoid, Kataklinger:
That was so simple. You are right, once again. I really do appreciate the help alot! It saves alot of headaches.
I can just swap the entire page, I don't know what I was thinking.

[Brendan]

Hi,

I'd be tempted to rewrite the Intel manual:

During a hardware task switch, the processor reads and writes into the first 104 bytes of each TSS (using contiguous physical addresses beginning with the physical address of the first byte of the TSS).

During a software task switch or an LTR instruction this wouldn't apply.

In any case, it would be possible to switch the IOMAP in a TSS struct by using linear mapping, as the IOMAP is never within the first 104 bytes. My Intel manual also says that the IO map base must be not exceed 0xDFFF, so you could have almost 56 KB of unused space between the start of the TSS and the start of the IOMAP. This means that the CPU must allow the TSS to cross a page boundary.

I guess this also means you could have a 64 KB TSS with seven different IO maps, and then change the IO map base. In this case each IOMAP would need to be a full 8192 bytes though (you couldn't have a "half sized" IOMAP and use the TSS limit to set the end of the IOMAP).

I wanted to create a TSS, at a address like this:

TSS = (0xA000 - sizeof(TSS))
So the last byte before the IOMAP resides at 0xAFFF.
Then map a private IOMAP for each process to:
IOMAP = 0xB000

You might want to double check that - "(0xA000 - sizeof(TSS))" would be 0x9F98 and the last byte would be 0x9FFF not 0xAFFF.

Or, does the IOMAP get cached? Can this cache get updated?

I doubt the IOMAP is cached, as the Intel manuals don't mention anything about it (and it'd need to in case the kernel changes the running task's access to one or more I/O ports).

I'd say it'd work fine...


Cheers,

Brendan

[Kevin McGuire]

@Brendon:
Awsome! Thats exactly what I want. Thanks. I did not read the docs thourly enough, I am glad you guys took the time to help me out. I appreciate it! Im glad to have people in a forum that know what they are doing.