]> git.ipfire.org Git - thirdparty/ipxe.git/commit
[efi] Veto the VirtualBox E1kNetDxe driver
authorMichael Brown <mcb30@ipxe.org>
Fri, 23 Jun 2023 14:03:30 +0000 (15:03 +0100)
committerMichael Brown <mcb30@ipxe.org>
Fri, 23 Jun 2023 15:51:10 +0000 (16:51 +0100)
commita029f4e13b54cfe87a04af7209a0d9744f3b7613
tree5f615a8059e4009058179d9b6d11c35370ae7314
parentae435cb4cc78183814f867686d278885db2988f8
[efi] Veto the VirtualBox E1kNetDxe driver

The VirtualBox E1kNetDxe driver has a Stop() method that relies on
being passed its own child device handle.  Unfortunately, the same
driver's Start() method never opens the parent device handle with
BY_CHILD_CONTROLLER attributes on behalf of the newly installed child
device handle, with the result that the UEFI device model is
completely unaware of the nominal parent-child relationship.  This
omission can be observed via the UEFI shell "devtree" command, which
will show the child SNP device handle as a standalone top-level device
handle, with no relationship to its underlying parent PCI device
handle.

The upshot of this omission is that the VirtualBox E1kNetDxe driver's
Stop() method is a pure no-op.  Calling DisconnectController() on the
PCI device handle will return successfully, but will not have actually
disconnected anything.  A subsequent attempt to open the handle on
behalf of iPXE's native Intel driver will get stuck in an infinite
loop inside OpenProtocol(), as the firmware repeatedly calls
DisconnectController() in an attempt to disconnect the E1kNetDxe
driver from the PCI device handle.

Work around this problem by adding the buggy VirtualBox E1kNetDxe
driver to the veto list.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/interface/efi/efi_veto.c