Using GPF to route IRQs

[Firestryke31]

I'm sure we all know that the GPF pushes an error code that says both what caused it and how it happened. It even tells whether it was a hardware or software interrupt. I was wondering, what benefits and disadvantages (other than being slow) would there be to routing all non-exception and non-NMI interrupts through the GPF? One relatively useless plus is that you could map software interrupts and hardware interrupts to the same number without conflict, as well as not having to set up the low level ISR stubs for all 256 interrupts (only 32 instead).

[Hangin10]

AFAIK, an error code only gets pushed if there was an exception, and there's no way to know whether an application triggered the interrupt (with the 'int' instruction). Also, hardware sharing interrupts is kind of a pain already (if not all devices support MSI).

It would be nice if the CPU would provide the vector number on the stack rather than needing as many entry points as interrupts though.

[Firestryke31]

The IDT is structured so that anything above int 0x20 causes a GPF. The GPF pushes which ISR caused the error, as well as some flags saying whether it was an interrupt or not and if it was software or hardware, and all automatically.

I have this setup working, I just was wondering advantages and disadvantages.

[Hangin10]

oh, ok, in that case, I guess the main two disadvantages would be the extra interrupt dispatch and the extra code to sort out what happened. It seems to that this is an overly complex way to avoid making 256 entry point stubs (which isn't difficult with assembler macros).

What would you say the advantage of this is?

[Firestryke31]

oh, ok, in that case, I guess the main two disadvantages would be the extra interrupt dispatch and the extra code to sort out what happened. It seems to that this is an overly complex way to avoid making 256 entry point stubs (which isn't difficult with assembler macros).

What would you say the advantage of this is?

I can't honestly think of any advantage.

I've got another disadvantage: Bochs loaths this dispatch method.

[technik3k]

Intel specification says that when executing INT<n> and if (n*8+7)>IDT_limit then it generates #GP(errorcode=n*8+2+ext). I am assuming that ext is flag indicating if this is external interrupt.

On the other hand spec for #GP says that if fault condition was detected while accessing a segment descriptor the error code contains segment selector to the descriptor or 0 otherwise.

So how do you distinguish between IRQ and erroneous code trying to use segment with selector 70h*8+2+1 ?

[Firestryke31]

In the error code there is always a flags field that indicates whether it was a GDT, IDT or LDT issue. I only do the ISR dispatch if the error code marks it as an IDT issue. With the internal/external flag, I can tell whether it was a software or hardware interrupt, and dispatch (or throw an error) accordingly (to keep software from sending false interrupts to hardware ISRs).

OSdev Wiki article