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?

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.