| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The CREATE_CQ command is permitted to return a size smaller than
requested, which could leave us in a situation where the completion
queue could overflow.
Avoid overflow by limiting the submission queue fill level to the
actual size of the completion queue.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Add a driver for the E810 family of 100 Gigabit Ethernet NICs. The
core datapath is identical to that of the 40 Gigabit XL710, and this
part of the code is shared between both drivers. The admin queue
mechanism is sufficiently similar to make it worth reusing substantial
portions of the code, with separate implementations for several
commands to handle the (unnecessarily) breaking changes in data
structure layouts. The major differences are in the mechanisms for
programming queue contexts (where the E810 abandons TX/RX symmetry)
and for configuring the transmit scheduler and receive filters: these
portions are sufficiently different to justify a separate driver.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Remove knowledge of the PRTGL_SA[HL] registers, and instead use the
admin queue to set the MAC address and maximum frame size.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Remove knowledge of the PRTPM_SA[HL] registers, and instead use the
admin queue to retrieve the MAC address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Allow for the MAC address to be fetched using an admin queue command,
instead of reading the PRTPM_SA[HL] registers directly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
The PRTGL_SAH register contains the current maximum frame size, and is
not guaranteed on reset to contain the actual maximum frame size
supported by the hardware, which the datasheet specifies as 9728 bytes
(including the 4-byte CRC).
Set the maximum packet size to a hardcoded 9728 bytes instead of
reading from the PRTGL_SAH register.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Remove knowledge of the GLLAN_RCTL_0 register (which changes location
between the XL810 and E810 register maps), and instead unconditionally
issue the "clear PXE mode" command with the EEXIST error silenced.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
The "clear PXE mode" admin queue command will return an EEXIST error
if the device is already in non-PXE mode, but there is no other admin
queue command that can be used to determine whether the device has
already been switched into non-PXE mode.
Provide a mechanism to allow expected errors from a command to be
silenced, to allow the "clear PXE mode" command to be cleanly used
without needing to first check the GLLAN_RCTL_0 register value.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
At least one E810 admin queue command (Query Default Scheduling Tree
Topology) insists upon being provided with a 4kB data buffer, even
when the data to be returned is much smaller.
Work around this requirement by increasing the admin queue data buffer
size to 4kB.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The E810 requires that receive descriptor rings have at least 64
entries (and are a multiple of 32 entries).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Use the tail register offset (which exists for all ring types) as the
ring identifier in all relevant debug messages.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
For the sake of completeness, ensure that all 32 bytes of the receive
queue context are programmed (including the unused final 8 bytes).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Commit 8f3e648 ("[intelxl] Use one admin queue buffer per admin queue
descriptor") changed the API for intelxl_admin_command() such that the
caller now constructs the command directly within the next available
descriptor ring entry, rather than relying on intelxl_admin_command()
to copy the descriptor to and from the descriptor ring.
This introduced a regression in intelxl_admin_switch(), since the
second and subsequent iterations of the loop will not have constructed
a valid command in the new descriptor ring entry before calling
intelxl_admin_command().
Fix by constructing the command within the loop.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Expose the system MAC address (if any) via the ${sysmac} setting.
This allows scripts to access the system MAC address even when iPXE
has decided not to apply it to a network device (e.g. because the
cached DHCPACK MAC address was selected in order to match the
behaviour of a previous boot stage).
The setting is named ${sysmac} rather than ${acpimac} in order to
allow for forward compatibility with non-ACPI mechanisms that may
exist in future for specifying a system MAC address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
When running on a system with an ACPI-provided system-specific MAC
address, iPXE will apply this address to an ECM or NCM USB NIC. If
iPXE has been chainloaded from a previous stage that does not
understand the ACPI MAC mechanism then this can result in iPXE using a
different MAC address than the previous stage, which is surprising to
users.
Attempt to minimise surprise by allowing the MAC address found in a
cached DHCPACK packet to override a temporary MAC address, if the
DHCPACK MAC address matches the network device's permanent MAC
address. When a previous stage has chosen to use the network device's
permanent MAC address (e.g. because it does not understand the ACPI
MAC mechanism), this will cause iPXE to make the same choice.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
When applying an ACPI-provided system-specific MAC address, apply it
to netdev->ll_addr rather than netdev->hw_addr. This allows iPXE
scripts to access the permanent MAC address via the ${netX/hwaddr}
setting (and thereby provides scripts with a mechanism to ascertain
that the NIC is using a MAC address other than its own permanent
hardware address).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Some newer HP products expose the host-based MAC (HBMAC) address using
an ACPI method named "RTMA" returning a part-binary string of the form
"_RTXMAC_#<mac>#", where "<mac>" comprises the raw MAC address bytes.
Extend the existing support to handle this format alongside the older
"_AUXMAC_" format (which uses a base16-encoded MAC address).
Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com>
Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
For symmetry with the stub user_to_phys() implementation, provide
phys_to_user() with the same underlying assumption that virtual
addresses are physical (since there is no way to know the real
physical address when running as a Linux userspace executable).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Allow for linked-in code to override the mechanism used to locate an
ACPI table, thereby opening up the possibility of ACPI self-tests.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Extend the glyph cache to include a number of dynamic entries that are
populated on demand whenever a non-ASCII character needs to be drawn.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Accumulate UTF-8 characters in fbcon_putchar(), and require the frame
buffer console's .glyph() method to accept Unicode character values.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
We currently define the active DNS server as a global variable. All
queries will start by attempting to contact the active DNS server, and
the active DNS server will be changed only if we fail to get a
response. This effectively treats the DNS server list as expressing a
weak preference ordering: we will try servers in order, but once we
have found a working server we will stick with that server for as long
as it continues to respond to queries.
Some sites are misconfigured to hand out DNS servers that do not have
a consistent worldview. For example: the site may hand out two DNS
server addresses, the first being an internal DNS server (which is
able to resolve names in private DNS domains) and the second being a
public DNS server such as 8.8.8.8 (which will correctly return
NXDOMAIN for any private DNS domains). This type of configuration is
fundamentally broken and should never be used, since any DNS resolver
performing a query for a name within a private DNS domain may obtain a
spurious NXDOMAIN response for a valid private DNS name.
Work around these broken configurations by treating the DNS server
list as expressing a strong preference ordering, and always starting
DNS queries from the first server in the list (rather than maintaining
a global concept of the active server). This will have the debatable
benefit of converting permanent spurious NXDOMAIN errors into
transient spurious NXDOMAIN errors, which can at least be worked
around at a higher level (e.g. by retrying a download in a loop within
an iPXE script).
The cost of always starting DNS queries from the first server in the
list is a slight delay introduced when the first server is genuinely
unavailable. This should be negligible in practice since DNS queries
are relatively infrequent and the failover expiry time is short.
Treating the DNS server list as a preference ordering is permitted by
the language of RFC 2132, which defines DHCP option 6 as a list in
which "[DNS] servers SHOULD be listed in order of preference". No
specification defines a precise algorithm for how this preference
order should be applied in practice: this new approach seems as good
as any.
Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
The BIOS console's interpretation of LShift+RShift as equivalent to
AltGr requires the shifted ASCII characters to be present in the AltGr
mapping table, to allow AltGr-Shift-<key> to be interpreted in the
same way as AltGr-<key>.
For keyboard layouts that have different ASCII characters for
AltGr-<key> and AltGr-Shift-<key>, this will potentially leave the
character for AltGr-<key> inaccessible via the BIOS console if the
BIOS requires the use of the LShift+RShift workaround. This
theoretically affects the numeric keys in the Lithuanian ("lt")
keyboard layout (where the numerals are accessed via AltGr-<key> and
punctuation characters via AltGr-Shift-<key>), but the simple
workaround for that keyboard layout is to avoid using AltGr and Shift
entirely since the unmodified numeric keys are not remapped anyway.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Provide the special keyboard map named "dynamic" which allows the
active keyboard map to be selected at runtime via the ${keymap}
setting, e.g.:
#define KEYBOARD_MAP dynamic
iPXE> set keymap uk
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Settings applicators are entirely independent, and there is no reason
why a failure in one applicator should prevent other applicators from
being processed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
As reported by Coverity, xsmp_rx_xve_modify() currently passes a
partially initialised struct ib_address_vector to xve_update_tca() and
thence to eoib_set_gateway(), which uses memcpy() to store the whole
structure including the (unused and unneeded) uninitialised fields.
Silence the Coverity warning by zeroing the whole structure.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
As per the general pattern for initialisation functions in iPXE,
pci_init() saves code size by assuming that the caller has already
zeroed the underlying storage (e.g. as part of zeroing a larger
containing structure). There are several places within the code where
pci_init() is deliberately used to initialise a transient struct
pci_device without zeroing the entire structure, because the calling
code knows that only the PCI bus:dev.fn address is required to be
initialised (e.g. when reading from PCI configuration space).
Ensure that using pci_init() followed by pci_read_config() will fully
initialise the struct pci_device even if the caller did not previously
zero the underlying storage, since Coverity reports that there are
several places in the code that rely upon this.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
Embedded images do not have an associated URI. This currently causes
the current working URI (cwuri) to be cleared when starting an
embedded image.
If the current working URI has been set via a ${next-server} setting
from a cached DHCP packet then this will result in unexpected
behaviour. An attempt by the embedded script to use a relative URI to
download files from the TFTP server will fail with the error:
Could not start download: Operation not supported (ipxe.org/3c092083)
Rerunning the "dhcp" command will not fix this error, since the TFTP
settings applicator will not see any change to the ${next-server}
setting and so will not reset the current working URI.
Fix by setting the current working URI to the image's URI only if the
image actually has an associated URI.
Debugged-by: Ignat Korchagin <ignat@cloudflare.com>
Originally-fixed-by: Ignat Korchagin <ignat@cloudflare.com>
Tested-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
