Appears there's something wrong in the PIC emulation.

I think IRQ1 keeps interrupting (or whatever the "Interrupt status: 0000000000000010" means), and it triggers the hardware interrupt handler execution.

But, the vector in question is set to catch spurious interrupts.

The spurious interrupt handler tries to read PIC in service register, but it says zero so it thinks no hardware interrupt is being serviced, so it can't disable the triggering interrupt.

Edit: yes the keyboard interrupt tries to send EOI to PIC, but this then triggers the spurious vector, while interrupt status stays as ...00000000010

Interrupt status 0000000000000010 is interrupt 1(It's the contents of the IRR register of the two PICs), so it's the keyboard interrupt(PIC auotomatically acnowledges when fired). So that means a problem with the keyboard?

Edit: Fixing the IRR lowering of the IR pins to not clear the IRR, as well as removing the hardware-controlled IRR clearing, both the XT and AT work again. Only software can acnowledge interrupts now, by sending an Acnowledge to the PIC(Any form of EOI). When the request is handled (interrupt is fired), IRR is cleared now. Simultaneous IR requests on the same IR line will be handled as one (when two devices on the same line raise IR, IR only gets raised once, but is only lowered when all devices that have raised it have lowered their connected IR line, thus preventing other devices from executing their interrupt when the first is handled). So if the two devices raise the same IR line, only the lowest registered device gets handled, the higher won't get handled. When the first device that handled the first IR request has been handled, the second device won't execute it's Interrupt Request until it lowers and raises it's IR line and the first IR isn't raised at the same time.