required interrupts
required interrupts
consider a kernel in protected mode
how many interrupt must be set by the kernel using LIDT?
what are they? all hardware interrupts?
how many interrupt must be set by the kernel using LIDT?
what are they? all hardware interrupts?
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
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?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
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...
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...
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.
You should maybe default initialize vectors corresponding to IRQs to a NOP-isr and all other to a generic fault handler.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Strange, the manuals seem to indicate otherwiseAnd Combuster - an interrupt descriptor without the Present flag set causes a double fault.
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:
and #NPIntel 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 #DF: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).
an INT/INTR(benign) followed by #GP or #NP (contributory) do not result in a doublefault, but are handled serially.
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).
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).
hate to be picky but...JamesM wrote:he points me to Manual 3A Section 5-38/5-39.
"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 correctionJAAman wrote:hate to be picky but...JamesM wrote:he points me to Manual 3A Section 5-38/5-39.
"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
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
I'll be more specific then. You don't need to define any interrupt handlers (I did not say exception handlers)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.
Oooh! That's a shoddy back-door escape route you found there! Good work!Combuster wrote:I'll be more specific then. You don't need to define any interrupt handlers (I did not say exception handlers)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.