lp:ipxe

Created by Peter J. Mello on 2020-01-06 and last modified on 2020-11-30
Get this branch:
bzr branch lp:ipxe

Related bugs

Related blueprints

Branch information

Owner:
Peter J. Mello
Project:
iPXE
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at https://github.com/ipxe/ipxe.git.

The next import is scheduled to run in 4 hours.

Last successful import was 1 hour ago.

Import started 1 hour ago on alnitak and finished 1 hour ago taking 20 seconds — see the log
Import started 7 hours ago on alnitak and finished 7 hours ago taking 20 seconds — see the log
Import started 13 hours ago on alnitak and finished 13 hours ago taking 20 seconds — see the log
Import started 20 hours ago on alnitak and finished 20 hours ago taking 20 seconds — see the log
Import started on 2020-12-04 on alnitak and finished on 2020-12-04 taking 20 seconds — see the log
Import started on 2020-12-04 on alnitak and finished on 2020-12-04 taking 20 seconds — see the log
Import started on 2020-12-03 on alnitak and finished on 2020-12-03 taking 20 seconds — see the log
Import started on 2020-12-03 on alnitak and finished on 2020-12-03 taking 20 seconds — see the log
Import started on 2020-12-03 on alnitak and finished on 2020-12-03 taking 20 seconds — see the log
Import started on 2020-12-03 on alnitak and finished on 2020-12-03 taking 20 seconds — see the log

Recent revisions

5791. By Michael Brown <email address hidden> on 2020-11-30

[efi] Veto the HP XhciDxe Driver

The HP XhciDxe driver (observed on an HP EliteBook 840 G6) does not
respond correctly to driver disconnection, and will leave the PciIo
protocol instance opened with BY_DRIVER attributes even after
returning successfully from its Stop() method. This prevents iPXE
from subsequently connecting to the PCI device handle.

Veto this driver if the iPXE build includes a native xHCI driver.

Signed-off-by: Michael Brown <email address hidden>

5790. By Michael Brown <email address hidden> on 2020-11-30

[efi] Allow vetoing of drivers that cannot be unloaded

Some UEFI drivers (observed with the "Usb Xhci Driver" on an HP
EliteBook) are particularly badly behaved: they cannot be unloaded and
will leave handles opened with BY_DRIVER attributes even after
disconnecting the driver, thereby preventing a replacement iPXE driver
from opening the handle.

Allow such drivers to be vetoed by falling back to a brute-force
mechanism that will disconnect the driver from all handles, uninstall
the driver binding protocol (to prevent it from attaching to any new
handles), and finally close any stray handles that the vetoed driver
has left open.

Signed-off-by: Michael Brown <email address hidden>

5789. By Michael Brown <email address hidden> on 2020-11-30

[efi] Provide manufacturer and driver names to all veto checking methods

Most veto checks are likely to use the manufacturer name and driver
name, so pass these as parameters to minimise code duplication.

Signed-off-by: Michael Brown <email address hidden>

5788. By Michael Brown <email address hidden> on 2020-11-30

[efi] Split out dbg_efi_opener() as a standalone function

Allow external code to dump the information for an opened protocol
information entry via DBG_EFI_OPENER() et al.

Signed-off-by: Michael Brown <email address hidden>

5787. By Michael Brown <email address hidden> on 2020-11-29

[xhci] Update driver to use DMA API

Signed-off-by: Michael Brown <email address hidden>

5786. By Michael Brown <email address hidden> on 2020-11-29

[dma] Provide dma_umalloc() for allocating large DMA-coherent buffers

Some devices (e.g. xHCI USB host controllers) may require the use of
large areas of host memory for private use by the device. These
allocations cannot be satisfied from iPXE's limited heap space, and so
are currently allocated using umalloc() which will allocate external
system memory (and alter the system memory map as needed).

Provide dma_umalloc() to provide such allocations as part of the DMA
API, since there is otherwise no way to guarantee that the allocated
regions are usable for coherent DMA.

Signed-off-by: Michael Brown <email address hidden>

5785. By Michael Brown <email address hidden> on 2020-11-29

[efi] Avoid requesting zero-length DMA mappings

The UEFI specification does not prohibit zero-length DMA mappings.
However, there is a reasonable chance that at least one implementation
will treat it as an invalid parameter. As a precaution, avoid calling
EFI_PCI_IO_PROTOCOL.Map() with a length of zero.

Signed-off-by: Michael Brown <email address hidden>

5784. By Michael Brown <email address hidden> on 2020-11-29

[netdevice] Fix misleading comment on netdev_rx()

Unlike netdev_rx_err(), there is no valid circumstance under which
netdev_rx() may be called with a null I/O buffer, since a call to
netdev_rx() represents the successful reception of a packet. Fix the
code comment to reflect this.

Signed-off-by: Michael Brown <email address hidden>

5783. By Michael Brown <email address hidden> on 2020-11-29

[netdevice] Do not attempt to unmap a null I/O buffer

netdev_tx_err() may be called with a null I/O buffer (e.g. to record a
transmit error with no associated buffer). Avoid a potential null
pointer dereference in the DMA unmapping code path.

Signed-off-by: Michael Brown <email address hidden>

5782. By Michael Brown <email address hidden> on 2020-11-28

[dma] Move I/O buffer DMA operations to iobuf.h

Include a potential DMA mapping within the definition of an I/O
buffer, and move all I/O buffer DMA mapping functions from dma.h to
iobuf.h. This avoids the need for drivers to maintain a separate list
of DMA mappings for each I/O buffer that they may handle.

Network device drivers typically do not keep track of transmit I/O
buffers, since the network device core already maintains a transmit
queue. Drivers will typically call netdev_tx_complete_next() to
complete a transmission without first obtaining the relevant I/O
buffer pointer (and will rely on the network device core automatically
cancelling any pending transmissions when the device is closed).

To allow this driver design approach to be retained, update the
netdev_tx_complete() family of functions to automatically perform the
DMA unmapping operation if required. For symmetry, also update the
netdev_rx() family of functions to behave the same way.

As a further convenience for drivers, allow the network device core to
automatically perform DMA mapping on the transmit datapath before
calling the driver's transmit() method. This avoids the need to
introduce a mapping error handling code path into the typically
error-free transmit methods.

With these changes, the modifications required to update a typical
network device driver to use the new DMA API are fairly minimal:

- Allocate and free descriptor rings and similar coherent structures
  using dma_alloc()/dma_free() rather than malloc_phys()/free_phys()

- Allocate and free receive buffers using alloc_rx_iob()/free_rx_iob()
  rather than alloc_iob()/free_iob()

- Calculate DMA addresses using dma() or iob_dma() rather than
  virt_to_bus()

- Set a 64-bit DMA mask if needed using dma_set_mask_64bit() and
  thereafter eliminate checks on DMA address ranges

- Either record the DMA device in netdev->dma, or call iob_map_tx() as
  part of the transmit() method

- Ensure that debug messages use virt_to_phys() when displaying
  "hardware" addresses

Signed-off-by: Michael Brown <email address hidden>

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers