Page 1 of 1

required interrupts

Posted: Tue Mar 18, 2008 5:05 am
by Philip
consider a kernel in protected mode
how many interrupt must be set by the kernel using LIDT?
what are they? all hardware interrupts?

Posted: Tue Mar 18, 2008 5:07 am
by JamesM
None.

Of course, if you get a fault your computer is going to triple fault and reset...

http://www.jamesmolloy.co.uk/tutorial_h ... 20IDT.html

see section 4.3.1

Posted: Tue Mar 18, 2008 5:11 am
by Philip
LIDT FAR PTR idtRegister
STI <--------------------------------- the computer restart here

Posted: Tue Mar 18, 2008 5:13 am
by Philip
JamesM wrote:None.

Of course, if you get a fault your computer is going to triple fault and reset...

http://www.jamesmolloy.co.uk/tutorial_h ... 20IDT.html

see section 4.3.1
if that's none: what if after STI an a hardware interrupt is triggered?

Posted: Tue Mar 18, 2008 5:23 am
by JamesM
Then your kernel will crash.

But you don't *need* any. Just don't enable interrupts.

And if you want to enable interrupts, then define interrupt handlers for all interrupts that can be generated by IRQs (see "remapping the PIC" on any tutorial ever).

And if you want to handle processor exceptions, define interrupt handlers for all interrupts that can be generated by the processor (see the link above).

Pretty simple, really...

Posted: Tue Mar 18, 2008 1:37 pm
by skyking
I'd say all should point somewhere defined by the time you start your first user process since that could trigger any software interrupt - and you want to at least be able to terminate such misbehaving processes instead of risking jumping into cybervoid.

You should maybe default initialize vectors corresponding to IRQs to a NOP-isr and all other to a generic fault handler.

Posted: Tue Mar 18, 2008 4:03 pm
by Combuster
Also note, an undefined interrupt will cause a GPF instead. You can route software and hardware interrupts to that handler instead of writing a separate handler.

Posted: Tue Mar 18, 2008 9:35 pm
by Philip
how to handle GPF?

Posted: Wed Mar 19, 2008 2:18 am
by JamesM
RTFM.

And Combuster - an interrupt descriptor without the Present flag set causes a double fault.

Posted: Wed Mar 19, 2008 5:28 am
by Combuster
And Combuster - an interrupt descriptor without the Present flag set causes a double fault.
Strange, the manuals seem to indicate otherwise :?

the INT instructions cause an exception when (among others)
#GP : the vector is outside the IDT limit
#GP : DPL < CPL for software interrupts. (hint @ skyking)
#NP : gate not present (Okay that was not a GPF. I stand corrected)

The list of #GP causes notes:
Intel manual vol 3 wrote:- Referencing an entry in the IDT (following an interrupt or exception) that is not an interrupt, trap, or task gate.
and #NP
An error code containing the segment selector index for the segment descriptor that caused the violation is pushed onto the stack of the exception handler. If the EXT flag is set, it indicates that the exception resulted from an external event (NMI or INTR) that caused an interrupt, which subsequently referenced a not-present segment. The IDT flag is set if the error code refers to an IDT entry (e.g., an INT instruction referencing a not-present gate).
and #DF:
an INT/INTR(benign) followed by #GP or #NP (contributory) do not result in a doublefault, but are handled serially.

Posted: Wed Mar 19, 2008 6:39 am
by JamesM
I know, I thought it was #GP first too, but my colleague is currently investigating this stuff and can confirm that no #GP takes place - he points me to Manual 3A Section 5-38/5-39.

That's the #DF exception page, and table 5.5 "Conditions for generating a double fault" we see that if the first exception is a page fault, then a contributary or page fault second exception generates a double fault immediately.

In this case the page fault handler is missing, another exception (be it #GP or #NP) *would* be thrown but is not - this is changed immediately into a double fault (which could, granted, be caught).

Posted: Wed Mar 19, 2008 9:04 am
by JAAman
JamesM wrote:he points me to Manual 3A Section 5-38/5-39.
hate to be picky but...

"5-38/5-39" isnt a section... its a page number, which, unlike section numbers, will be different if you have a different revision (or the same revision in a different language) of the manuals (in my latest hardcopy (019US), those pages are for the 2nd half of #DF, and interupt 9 (only used on 386 systems with co-processors) -- not exactly what you wanted (the section number would be 3A:5.15 interrupt 8 ) -- older or newer copies could be even further off

Posted: Wed Mar 19, 2008 9:13 am
by JamesM
JAAman wrote:
JamesM wrote:he points me to Manual 3A Section 5-38/5-39.
hate to be picky but...

"5-38/5-39" isnt a section... its a page number, which, unlike section numbers, will be different if you have a different revision (or the same revision in a different language) of the manuals (in my latest hardcopy (019US), those pages are for the 2nd half of #DF, and interupt 9 (only used on 386 systems with co-processors) -- not exactly what you wanted (the section number would be 3A:5.15 interrupt 8 ) -- older or newer copies could be even further off
Fair enough! Thanks for the correction :)

Posted: Wed Mar 19, 2008 10:42 am
by Combuster
That's the #DF exception page, and table 5.5 "Conditions for generating a double fault" we see that if the first exception is a page fault, then a contributary or page fault second exception generates a double fault immediately.
I'll be more specific then. You don't need to define any interrupt handlers (I did not say exception handlers)

Posted: Wed Mar 19, 2008 11:57 am
by JamesM
Combuster wrote:
That's the #DF exception page, and table 5.5 "Conditions for generating a double fault" we see that if the first exception is a page fault, then a contributary or page fault second exception generates a double fault immediately.
I'll be more specific then. You don't need to define any interrupt handlers (I did not say exception handlers)
Oooh! That's a shoddy back-door escape route you found there! Good work! ;)