summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/intelxlvf.c
Commit message (Collapse)AuthorAgeFilesLines
* [intelxl] Explicitly request a single queue pair for virtual functionsMichael Brown2022-08-161-1/+44
| | | | | | | | | | | | | | | | Current versions of the E810 PF driver fail to set the number of in-use queue pairs in response to the CONFIG_VSI_QUEUES message. When the number of in-use queue pairs is less than the number of available queue pairs, this results in some packets being directed to nonexistent receive queues and hence silently dropped. Work around this PF driver bug by explicitly configuring the number of available queue pairs via the REQUEST_QUEUES message. This message triggers a VF reset that, in turn, requires us to reopen the admin queue and issue an additional GET_RESOURCES message to restore the VF to a functional state. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Allow for admin commands that trigger a VF resetMichael Brown2022-08-161-13/+28
| | | | | | | | | | | | The RESET_VF admin queue command does not complete via the usual mechanism, but instead requires us to poll registers to wait for the reset to take effect and then reopen the admin queue. Allow for the existence of other admin queue commands that also trigger a VF reset, by separating out the logic that waits for the reset to complete. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Negotiate virtual function API version 1.1Michael Brown2022-08-161-1/+6
| | | | | | | Negotiate API version 1.1 in order to allow access to virtual function opcodes that are disallowed by default on the E810. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Show virtual function packet statistics for debuggingMichael Brown2022-08-161-0/+59
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Separate virtual function driver definitionsMichael Brown2022-08-111-50/+56
| | | | | | | Move knowledge of the virtual function data structures and admin command definitions from intelxl.h to intelxlvf.h. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Reuse admin command descriptor and buffer for VF responsesMichael Brown2022-08-111-13/+15
| | | | | | | | | Remove the large static admin data buffer structure embedded within struct intelxl_nic, and instead copy the response received via the "send to VF" admin queue event to the (already consumed and completed) admin command descriptor and data buffer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Handle admin events via a callbackMichael Brown2022-08-111-5/+14
| | | | | | | | The physical and virtual function drivers each care about precisely one admin queue event type. Simplify event handling by using a per-driver callback instead of the existing weak function symbol. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Rename 8086:1889 PCI ID to "iavf"Michael Brown2022-08-101-1/+1
| | | | | | | | | | | The PCI device ID 8086:1889 is for the Intel Ethernet Adaptive Virtual Function, which is a generic virtual function that can be exposed by different generations of Intel hardware. Rename the PCI ID from "xl710-vf-ad" to "iavf" to reflect that the driver is not XL710-specific. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Negotiate API version for virtual function via admin queueMichael Brown2022-08-101-0/+46
| | | | | | | | | | Do not attempt to use the admin commands to get the firmware version and report the driver version for the virtual function driver, since these will be rejected by the E810 firmware as invalid commands when issued by a virtual function. Instead, use the mailbox interface to negotiate the API version with the physical function driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Use non-zero MSI-X vector for virtual function interruptsMichael Brown2022-08-101-4/+6
| | | | | | | | The 100 Gigabit physical function driver requires a virtual function driver to request that transmit and receive queues are mapped to MSI-X vector 1 or higher. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Fix invocation of intelxlvf_admin_queues()Michael Brown2022-08-101-1/+1
| | | | | | | The second parameter to intelxlvf_admin_queues() is a boolean used to select the VF opcode, rather than the raw VF opcode itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Use function-level reset instead of PFGEN_CTRL.PFSWRMichael Brown2022-08-081-1/+1
| | | | | | | | Remove knowledge of the PFGEN_CTRL register (which changes location between XL710 and E810 register maps), and instead use PCIe FLR to reset the physical function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise function-level reset mechanismMichael Brown2022-08-081-20/+3Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Move I/O buffer DMA operations to iobuf.hMichael Brown2020-11-281-16/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [dma] Modify DMA API to simplify calculation of medial addressesMichael Brown2020-11-251-2/+4
| | | | | | | | | | | | | | | | | Redefine the value stored within a DMA mapping to be the offset between physical addresses and DMA addresses within the mapped region. Provide a dma() wrapper function to calculate the DMA address for any pointer within a mapped region, thereby simplifying the use cases when a device needs to be given addresses other than the region start address. On a platform using the "flat" DMA implementation the DMA offset for any mapped region is always zero, with the result that dma_map() can be optimised away completely and dma() reduces to a straightforward call to virt_to_phys(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Configure DMA mask as 64-bitMichael Brown2020-11-241-1/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Update driver to use DMA APIMichael Brown2020-11-211-18/+21
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Update drivers to use pci_ioremap()Michael Brown2020-09-251-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intelxl] Add driver for Intel 40 Gigabit Ethernet NIC virtual functionsMichael Brown2019-04-271-0/+719
Signed-off-by: Michael Brown <mcb30@ipxe.org>