If you think about the hardware set a VM uses, it then makes sense. It is either a synthetic device or an emulated one. Emulated devices use the host’s kernel, and synthetic drivers go through/use a hypervisor that is under the kernel and therefore doesn’t need to wait for kernel mode interrupts. But in either case, there is only one video driver, one sound driver, one keyboard/mouse driver, etc., etc.
I think this points to the hardest thing the software has to do is perfectly map hardware’s primitives, I.e., machine code instructions, when there is so much disparate hardware out there. And then add to that that different assemblages of hardware can further muddle up driver code that would be fine by itself.
Aside from operator error, this is the hardest thing to test for. Who knew that one guy would still be using that piece of crap, cheap Chinese scanner and how it’s driver had to fake out some interrupt needed by every component ?
Over my years as a system design engineer I had to "fake out" more bizarre crap than you can imagine, or maybe you can. :-)
Abstraction layers, wrappers around wrappers around driver code, translation tables, yikes. You obviously know what I'm talking about.
Emulating interrupt handling was a lot harder in the old days when CPUs were a literally thousand times slower. That was one reason I preferred the 6502 to the 6800 for real-time interrupt handling. The 6800 pushed every register onto the stack before entering the interrupt service routine, which took quite a while, whereas the 6502 just pushed the PC and status register, so you could get to handling the interrupt faster. Of course if you needed other registers in the handler you had to push them first, but that encouraged the handler writer to get the necessary stuff done with as few registers as possible, do the RTI, and get back to mainline. For the same clockrate I could get a 6502 to handle a small interrupt service task in less than half the time of the 6800.
Ah, those were the days.... :-)