How does the BIOS distinguish Interrupt(08h-12h) from INT instructions, vs. actual exceptions inside the CPU?

Question

This is purely academic, out of date, out of curiosity. Let's back to 1990s, before the Windows, when real-mode DOS programs were common.

The BIOS remapped the INT 08H+ for their own interrupt handler, for instance, int 10H for VGA MODE switch, int 13H for hard driver. (Table of software-interrupt numbers)

But, as we can see in Intel® 64 and IA-32 Architectures Software Developer Manuals, we can know that there are also many real-address exception that can cause interrupt. For example, #DE divide exception raising interrupt vector 0h, or x87 FPU raising 10h (https://wiki.osdev.org/IVT)

If a programmer intentionally or unintentionally makes the CPU raise those exceptions on its own, by running instructions like bound that can trigger a BOUND Range Exceeded exception, how does the BIOS or anything else distinguish that from an INT 5 software interrupt to make as PRINT SCREEN call, for instance. It's the same IVT entry so the same interrupt handler will be invoked for either case.

What's more, IRQ makes if you want to use keyboard you can't trigger those interrupts. (OSdev IRQ assignments table)

As so many Intel's default interrupt is remapped by the bios, things became unreasonable.

---

This was cross-posted to retrocomputing.SE and also has an answer there.

Answer 1

How does the BIOS distinguish Interrupt(08h-12h) from INT instructions, vs. actual exceptions inside the CPU?

Mostly it doesn't. It assumes interrupts 0x08 to 0x0F are IRQs (from PIC chip/devices); does nothing useful when the interrupt is a software interrupt (and sends an EOI to PIC chip that can cause problems in some cases); and crashes and/or locks up (via. an "exception -> return to faulty code -> exception -> return to faulty code ..." loop) when its an exception.

In theory it's possible to ask the corresponding PIC chip if there's an IRQ in service to tell the difference between a real IRQ and other causes (software interrupt, exception and "spurious IRQ 7 or 15"); and also possible to examine the bytes at "return CS:IP" to tell the difference between a software interrupt and other causes (exception, spurious IRQ). There is no "exception 0x0F" (it's reserved); so this set of "possible in theory" covers all of the cases.

Nobody does it.

An OS solves the problem by reconfiguring the PIC chip and/or IO APIC to ensure there's no conflicts between exceptions and IRQs, and using privilege levels to ensure that a software interrupt for interrupts used by exceptions or IRQs cause a general protection fault.