How are BIOS interrupts deconflicted with reserved hardware interrupts?

Question

I'm reading a section of kernel bootloader code (from Stanford's CS140 Pintos OS):

# Configure serial port so we can report progress without connected VGA.
# See [IntrList] for details.
        sub %dx, %dx                    # Serial port 0.
        mov $0xe3, %al                  # 9600 bps, N-8-1.
                                        # AH is already 0 (Initialize Port).
        int $0x14                       # Destroys AX.

The processor is executing these instructions in real address mode. Presumably the interrupt is handled by find the 21st (index=0x14) entry of the Interrupt Vector Table and executing the handler there. According to this source, the interrupt table is initialized by BIOS in real mode. This Wikipedia page lists BIOS interrupts that are available, including the one used above.

My confusion comes from the fact that the interrupt exception numbers listed conflict substantially with the descriptions of Real Mode reserved interrupts in the Intel reference (page 20-6) (and also repeated in this Wikipedia page)

How are those interrupt numbers de-conflicted?

Alleman

They aren't "deconflicted". Intel reserved interrupts up to 1Fh for CPU use but IBM ignored that and assigned other usages to most of these. Int 0, 1, 3, 6 are used only for their CPU-related meanings. Particularly int 0Ch "stack fault" and int 0Dh "general protection fault" are problematic, and also used for IRQ hardware interrupts in the ROM-BIOS's default setup. If needed a handler has to check specifically why it was called. Example – Albie

whoever gets there last wins... – Preussen

Answer 1

I think the legend goes back to IBM didn't bother to read the intel architecture manual when they made the PC. Intel, from the first 8086, reserved the first 32 vectors for hardware use; IBM spec'd the PC BIOS ignoring this, and started services at 16 (0x10 -- video services); with one weird one at vector 5 for printing the current page of the video screen. Vector 5 is used by the bounds check instruction.

Interrupt 0x10 lives on as a "coprocessor error"; a remnant of when the floating point processor was an optional auxiliary chip.

Interrupt 0x14, which concerns you, was defined by the bios for serial port handling; and by the CPU as a virtualization exception.

When you are in real mode, there is no virtualization; thus there is no conflict. If you are in a virtual execution mode, and execute an int $0x14, the cpu just follows the idt; since the real virtual exception is caused by an access violation in the virtual machine, and causes an exit to the virtual machine monitor. [ exit is the term used by hypervisor people for the conditions that cause the virtual machine to stop executing ].

So, there is no ambiguity, just a somewhat idiotic adherence to a badly constructed interface.

Atc

So the "deconflicting" which exists is that the IVT loaded by BIOS is superseded by the interrupt table loaded later by the kernel (and which presumably complies with Intel's specifications)? – Alleman

Yes; currently the bios is only used for real mode bootstrapping; after that the target OS replaces the IVT with its own. – Atc