I agree that is was good the designers of the 386 got rid of some cruft in designing 386 protected mode. It's unfortunate they didn't lean harder into BIOS cal

I agree that is was good the designers of the 386 got rid of some cruft in designing 386 protected mode. It's unfortunate they didn't lean harder into BIOS calls to hide implementation details (such as allowing only the BIOS to manipulate page tables, and enforcing this by having the BIOS be the only ring0 component), effectively making the BIOS a hypervisor that only supported one guest kernel at a time. This is what the DEC Alpha did with its PALCode, and would have given a smaller interface that needed to be maintained in the future. It would have made writing a BIOS more complicated, but would have made future kernel and hardware work more simple. It would also have meant all 32-bit and 64-bit kernels would have been paravirtualized from day 1, greatly reducing the need for hardware emulation in multi-guest hypervisors. Of course, hindsight is 20/20, and it a business risk to depend so much on BIOS implementors unless you provide them a robust liberally licensed reference implementation to tailor to their hardware.