OSDev.org

Hi.
If there's any possible the base address of new Task in Task Gate is not present?
for example
The base address of the Task Gate is 0x80500080, But the linear address can not be found when Paging is enabled.

Hi,

watermirror wrote:Hi.
If there's any possible the base address of new Task in Task Gate is not present?
for example
The base address of the Task Gate is 0x80500080, But the linear address can not be found when Paging is enabled.

Yes. The TSS (that the task gate's base address points to) must be where the task gate says it is in the current virtual address space whenever the CPU needs to access anything in that TSS.

"Whenever the CPU needs to access anything in that TSS" can be defined as:

• whenever the CPU changes to a higher privilege level (e.g. CPL=3 code being interrupted by an IRQ that causes a switch to CPL=0 where the CPU needs to access the "SS0" and "ESP0" fields of the TSS)
• when switching to a different task via. hardware task switching; where the CPU has to write register values into the old task's TSS
• when switching to a different task via. hardware task switching; where the CPU has to read register values from the new task's TSS

This means that for hardware task switching the CPU expects 2 different TSSs to be where their task gates say they are at the same time. The likely end result of this is that all TSS typically end up in all virtual address spaces all the time (to avoid complications - e.g. so you can switch from one task/TSS to another whenever you like without messing about).

Also note that the opposite is also true - the task gate's base address doesn't need to be sane whenever the CPU doesn't need to access the TSS. This mostly only occurs whenever you're running kernel code (when no privilege level switching is possible) if that kernel code isn't doing any hardware task switching (software task switching would be fine).


Cheers,

Brendan

Hi,Brendan, Thanks for the explain.

I think ,If the TSS is not in current virtual address space, there should be a Page Fault Exception to Handle this, is that right?

Hi,

watermirror wrote:I think ,If the TSS is not in current virtual address space, there should be a Page Fault Exception to Handle this, is that right?

Yes.

Also, if the task switch was attempted by normal software, the page fault exception handler can fix the problem and return to the instruction that caused the page fault (so that the instruction/task switch is retried). However; if the task switch was caused by an IRQ handler this doesn't work (there is no instruction to retry).


Cheers,

Brendan

Hi, Brendan

However; if the task switch was caused by an IRQ handler this doesn't work (there is no instruction to retry).

Can you tell me in what situtation the task switch will be caused by IRQ handler?

there is no instruction to retry

and I still can not understand this.

watermirror wrote:

there is no instruction to retry

and I still can not understand this.

An interrupt (other than a software one) is an external signal to the CPU. If it causes a fault you can't go back and get it sent again.

iansjack wrote:

watermirror wrote:

there is no instruction to retry

and I still can not understand this.

An interrupt (other than a software one) is an external signal to the CPU. If it causes a fault you can't go back and get it sent again.

I think that is wrong. If the IDT entry is a task-gate, and the task gate has problems, you will get fault-codes indicating the destination (which is your link to the IRQ). If the IDT entry itself is faulty, you get some other fault which indicate the source as an IRQ.

If IRQs could just get lost, you'd have a very bad hardware design, and this is not true. Bad programming could cause them to become lost, but not the processor design in itself.

Hi,

rdos wrote:

iansjack wrote:

watermirror wrote:and I still can not understand this.

An interrupt (other than a software one) is an external signal to the CPU. If it causes a fault you can't go back and get it sent again.

I think that is wrong. If the IDT entry is a task-gate, and the task gate has problems, you will get fault-codes indicating the destination (which is your link to the IRQ). If the IDT entry itself is faulty, you get some other fault which indicate the source as an IRQ.

It's not wrong.

The full sequence of events is:

• An IRQ occurs
• CPU checks IDT and finds a task gate (any/all protection checks passed)
• CPU checks GDT and finds the target task's TSS descriptor (any/all protection checks passed)
• CPU checks TSS descriptor for the current/interrupted task (any/all protection checks passed)
• CPU writes the interrupted task's state to its TSS (any/all protection checks passed)
• CPU attempts to read the target task's TSS and detects a page fault
• CPU backs out of the task switch (restoring the original/interrupted task's state)
• CPU starts the page fault exception handler

At this point, the page fault handler only has the information that the CPU gives it, which is limited to the address that the CPU couldn't load (CR2), the error code (if the problem was a read/write, privilege violation, etc), and the return address (the address of within the task that was interrupted by the IRQ). The page fault handler can't even figure out if the page fault was caused by an IRQ or not without using "magic voodoo" (e.g. making assumptions based on CR2 and hoping that kernel code didn't do an explicit read).

rdos wrote:If IRQs could just get lost, you'd have a very bad hardware design, and this is not true. Bad programming could cause them to become lost, but not the processor design in itself.

Um, if your OS has a TSS that is required by an IRQ handler, and that TSS isn't in the virtual address space when the IRQ occurs, then it's extremely bad software design (and not bad hardware design at all). Basically, if you screw things up this badly then you shouldn't be blaming anyone except yourself.


Cheers,

Brendan

Brendan wrote:Hi,

rdos wrote:

iansjack wrote:An interrupt (other than a software one) is an external signal to the CPU. If it causes a fault you can't go back and get it sent again.

I think that is wrong. If the IDT entry is a task-gate, and the task gate has problems, you will get fault-codes indicating the destination (which is your link to the IRQ). If the IDT entry itself is faulty, you get some other fault which indicate the source as an IRQ.

It's not wrong.

The full sequence of events is:

• An IRQ occurs
• CPU checks IDT and finds a task gate (any/all protection checks passed)
• CPU checks GDT and finds the target task's TSS descriptor (any/all protection checks passed)
• CPU checks TSS descriptor for the current/interrupted task (any/all protection checks passed)
• CPU writes the interrupted task's state to its TSS (any/all protection checks passed)
• CPU attempts to read the target task's TSS and detects a page fault
• CPU backs out of the task switch (restoring the original/interrupted task's state)
• CPU starts the page fault exception handler

At this point, the page fault handler only has the information that the CPU gives it, which is limited to the address that the CPU couldn't load (CR2), the error code (if the problem was a read/write, privilege violation, etc), and the return address (the address of within the task that was interrupted by the IRQ). The page fault handler can't even figure out if the page fault was caused by an IRQ or not without using "magic voodoo" (e.g. making assumptions based on CR2 and hoping that kernel code didn't do an explicit read).

OK. You are right (in this specific case). You cannot have pagefaults in the TSS switch process, and active TSSes must always be present in physical memory. However, if we exclude page faults, I think it is wrong that IRQs are lost when there are other faults. For instance, if an IRQ causes a general protection fault, the errorcode will identify the reason as an IRQ, and also the specific IRQ #, so this is a case where the IRQ is not lost.

Brendan wrote:

rdos wrote:If IRQs could just get lost, you'd have a very bad hardware design, and this is not true. Bad programming could cause them to become lost, but not the processor design in itself.

Um, if your OS has a TSS that is required by an IRQ handler, and that TSS isn't in the virtual address space when the IRQ occurs, then it's extremely bad software design (and not bad hardware design at all). Basically, if you screw things up this badly then you shouldn't be blaming anyone except yourself.

Agreed, and my OS certainly doesn't use non-present TSSes, and don't even use TSS for IRQs.

depends on the error occurring during the interrupt control transfer. Generally afaik, EXT can be set as long as the transfer wasn't done using INT n, but the error code will vary depending on the plethora of possible errors that can theoretically occur.

bottom line anyway is (as i'm sure you know) that unless there is something very wrong with your kernel situation you shouldn't be having this problem.