[xhci] Do not release ownership back to BIOS when booting an OS
authorMichael Brown <mcb30@ipxe.org>
Wed, 18 Mar 2015 11:57:41 +0000 (11:57 +0000)
committerMichael Brown <mcb30@ipxe.org>
Wed, 18 Mar 2015 12:35:16 +0000 (12:35 +0000)
commitec0e2a7bd77c3021bb492ccb78855482312bca4b
treef85917e04a3dfbf112b5fceee3bb46940f1ece91
parente1feb7bcab139a9b1114b8cc9e081d1144f53d75
[xhci] Do not release ownership back to BIOS when booting an OS

xHCI (and EHCI) nominally provide a mechanism for releasing ownership
of the host controller back to the BIOS, which can then potentially
restore legacy USB keyboard functionality.

This is a rarely used code path, since most operating systems claim
ownership and never attempt to later return to the BIOS.  On some
systems (observed with a Lenovo X1 Carbon), this code path leads to
obscure and interesting bugs: if the xHCI and EHCI controllers are
both claimed and later released back to the BIOS, then a subsequent
call to INT 16,0305 to set the keyboard repeat rate to a non-default
value will lock the system.

Obscure though this sequence of operations may sound, it is exactly
what happens when using iPXE to boot a Linux kernel via a USB network
card.  There is old and probably unwanted code in Linux's
arch/x86/boot/main.c which sets the keyboard repeat rate (with the
accompanying comment "Set keyboard repeat rate (why?)").  When booting
Linux via a USB network card on a Lenovo X1 Carbon, the system
therefore locks up immediately after jumping to the kernel's entry
point.

Work around this problem by preventing the release of ownership back
to the BIOS if it is known that we are shutting down to boot an OS.
This should allow legacy USB keyboard functionality to be restored if
the user chooses to exit iPXE, while avoiding the rarely used code
paths (and corresponding BIOS bugs) if the user chooses instead to
boot an OS.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/drivers/usb/xhci.c