aio_mlock.2: Expand document description
+ The old one renders broken because Xr is not correct/portable in Nd
+ Take this opportunity to explain it better using mlock description
MFC after: 3 days
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D61334
tests/sys/kern/ssl_sendfile: double timeouts for :grow and :truncate
The :grow and :truncate testcases fail semi-regularly in CI with
timeouts. Double the timeout to reduce false positives with the tests.
PR: 300699
MFC after: 1 week
Reviewed by: siva
Differential Revision: https://reviews.freebsd.org/D61444
asmc: include sys/kernel.h
This is needed for the `MODULE*` macros.
This include was accidentally removed in the linked commit.
MFC after: 1 week
Reported by: Ian Freislich <ianfreislich at gmail.com>
Fixes: c714cde179a4 ("asmc: split the sysctl layer into asmcsysctl.c")
iflib: Use a single tx dma map
The need for a separate map for TSO and non-TSO seems to have arisen from
a misunderstanding about the DMA requirements for Intel drivers like
ice/ixl/iavf. Specifically, this Intel hardware has a quirk where no
more than N (=8) segs can be DMA'ed per packet on the wire. This limit
was enforced using a DMA map with a low segment limit for non-TSO and a
driver specific check for TSO. This led to a *lot* of complexity in
iflib (~80 extra lines of code that this change removes) when the
limit can simply be enforced via the existing EFBIG mechanisms.
This change adds a new flag, IFLIB_SPARSE_TX, that drivers for hardware
with this quirk must set. When set, it causes non-TSO sends that
exceed isc_tx_nsegment to be treated as if bus_dmamap_load_mbuf_sg()
had returned EFBIG.
Due to the API/KABI change, I've bumped the FreeBSD version as well.
Note kgalazka suggested the flag, rather than a more awkward
[12 lines not shown]
snmp_hostres(3): strengthen work on the devd(8) socket
Use the SOCK_SEQPACKET version of the socket. This guarantees that
messages read won't be glued together. Use sufficient buffer size to
read any message.
Close socket on any kind of error or a short read.
This also fixes a bug when a SOCK_STREAM socket containing exactly
multiple of 512 bytes would block the daemon in read(2) until some
other devd(8) event. Thank to David for catching and analyzing it.
Reported by: David Pfitzner <dpfitzner at netflix.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61146
devd: expose maximum record size via sysconf(3)
Use UMA allocation size that holds the buffer. The buffer is actually
slightly smaller. Document the latter so that clients don't need to use
+1 if they later want to NUL-terminate a message.
Reviewed by: mjg, imp
Differential Revision: https://reviews.freebsd.org/D61346
devd: define _PATH_DEVD_SOCKET in <paths.h>
Sweep through consumers and use the define.
Reviewed by: kfv, imp
Differential Revision: https://reviews.freebsd.org/D61344
iflib: simplify TXQ_AVAIL
Simply the TXQ_AVAIL() macro to avoid using
get_inuse(txq->ift_size, txq->ift_cidx, txq->ift_pidx, txq->ift_gen)
and instead define it in terms of txq->ift_in_use.
Note that in_use is equivalent, because it is updated at the same time
as cidx/pidx and gen, and under the same serialization. The advantage
is that its cheaper due to using one read and no branches, and
safer, since unlocked reads get an atomic snapshot of availability,
but an unlocked read of multiple counters can produce inconsistent
results.
Reviewed by: kbowling, kgalazka
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D61279
(cherry picked from commit 44df82b11c535ae50b1e5888a361a2bd15d4182b)
iflib: rate limit deferred tx ring drain
When simple_tx gives up & return ENOBUFS because the tx ring is full,
we were doing a GROUPTASK_ENQUEUE(&txq->ift_task) each time.
On a tx ring that has overflowed and is being hammered on
by a fast UDP sender, this can result in a massive increase in
context switches (I've seen over 30M ctxw/sec due to this, and
the ctxsw codepath taking roughly 50% CPU).
This change removes the GROUPTASK_ENQUEUE() and replaces it
with a call to a callout which drains the tx ring. The callout time is
determined based on the link speed, estimating how long it would take
for a large fraction of of a ring containing full-MTU packets to drain.
This removes the 30M ctxsw / sec in my test case and reduces it
to roughly a doubling of ctxsws.
Reviewed by: kbowling
Sponsored by: Netflix
[3 lines not shown]
tpm: crb: Support the ACPI start method
Some AMD firmware TPMs report StartMethod 2 and had no driver. They never
acknowledge CTRL_REQ, so skip the idle and ready requests.
Do not harvest entropy from these TPMs on AMD: on a Ryzen 7 7735HS each
periodic TPM2_GetRandom froze every CPU, for up to 1.2 s (AMD PA-410).
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/103
(cherry picked from commit 6af18560a124b84549713a5f2b667a1df0990929)
tpm_crb: Use locality registers only with plain CRB
The locality release wait times out on every command on a Framework 13
(Pluton start method), logging every 10 seconds.
Reported by: emaste, tuexen
Reviewed by: kbowling
Approved by: kbowling
Fixes: bfe4be85a935 ("tpm_crb: wait for idle and locality release after each command")
(cherry picked from commit 1dade7024457ee10df1ccae22e3c454e80f82b76)
tpm_crb: wait for idle and locality release after each command
transmit only requested GO_IDLE and the locality release, so a back-to-back
command could see stale state and fail with EIO.
A post-send idle timeout no longer discards a completed response.
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/93
(cherry picked from commit bfe4be85a9354b92135e105028f2e1b3e0307ada)
tpm: crb: Dump register state on command failures
Include the command code in notification failures and the command code
and execution timeout in completion failures. Capture CRB control
registers on completion timeouts and Pluton mailbox readiness or
acknowledgement timeouts, before cancellation or cleanup changes them.
Include locality registers when present and mailbox registers for the
Pluton start method. The dump contains transport state without command
payloads or response data.
Tested by: olivier, tuexen
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
(cherry picked from commit 915eb355d8fe8555f7a74c6db95bc3c02610a939)
tpm: crb: Correct the Pluton mailbox handshake
Pluton's REPLY register indicates readiness for a new notification, not
completion of the notification just sent. Wait for REPLY=1 before
ringing the mailbox, then wait for START=0 when a synchronous state
change needs acknowledgement.
Use a separate command notification callback that waits for mailbox
readiness but leaves command completion to the existing CRB_CTRL_START
polling. Bound readiness waits by TPM_TIMEOUT_C, including asynchronous
idle notifications, while retaining the command's execution timeout.
This resolves reported command timeouts on a Framework AMD laptop.
Tested by: olivier, tuexen
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61128
(cherry picked from commit 4995fd4bf2c61e30363e588c5b90d7fc9145bf5e)
ixgbe: Restore EEE exclusion for X550EM_X KR
X550EM_X KR devices do not support EEE and have no setup_eee operation.
The shared-code update restored the capability removed by d61b6a41dd30,
and the E610 EEE support subsequently added an unchecked call during
attach. Together these changes allow a NULL function pointer call when
attaching a KR device.
Remove the incorrect EEE capability and use the NULL-safe ixgbe_setup_eee()
wrapper when enabling EEE at attach.
Removing the unsupported capability also stops exposing eee_state and the
eee.tx_lpi_count and eee.rx_lpi_count sysctls on X550EM_X_KR devices.
Fixes: f72de14ea132 ("ixgbe: update if_ix and ixgbe api with ix-3.3.38 changes")
Fixes: 13ee84c591f8 ("ix(4): Add EEE support for E610 adapters")
Sponsored by: BBOX.io
(cherry picked from commit 4678f9d8dc1324da6c021dc9d376a4671e72ad97)
ixgbe: Guard E610 Link Default Override access
Reading Link Default Override uses the E610 Admin Command Interface,
whose mutex is initialized only on E610. Calling it on other adapters
can hang attach, as observed on X520.
Skip the read on non-E610 devices, leaving the cached policy invalid so
that the existing link-state guard also skips force-link commands.
Reviewed by: kgalazka
Fixes: 7868958f5c79 ("ix(4): Support Total Port Shutdown on E610")
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D61144
(cherry picked from commit 2c6b01416f80462b393bbe70a38cea017325dea8)
ix(4): Support Total Port Shutdown on E610
Firmware controls the physical link state on E610 adapters, similarly to
X700 and E800 adapters. As a result, running "ifconfig down" does not
disable the physical link unless Total Port Shutdown is enabled.
Read the Link Default Override TLV from NVM to detect when Total
Port Shutdown was enabled for given port in system setup. In that
case, force the link down when the interface is stopped and restore
it during link configuration. Leave link state management unchanged
when the TLV is unavailable or the feature is not enabled.
Co-authored-by: Miłosz Linkiewicz <milosz.linkiewicz at intel.com>
Co-authored-by: Tomasz Lichwala <tomasz.lichwala at intel.com>
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Tested by: Mateusz Moga <mateusz.moga at intel.com>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D60643
[2 lines not shown]
ixl(4): Enable building driver on ARM64
For consistency with other drivers enable building ixl
on ARM64 target.
Please be advised that it is only compile tested.
Intel will continue to test Ethernet drivers only on x86-64
platforms, and is not going to provide support for issues,
which cannot be reproduced in such environment.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Suggested by: Dave Cottlehuber <dch at FreeBSD.org>
Reviewed by: manu
Approved by: kbowling (mentor)
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D54289
(cherry picked from commit a3d472219c5aa3c211371aebd2effbfade61cb5c)
iavf: Honor negotiated VLAN offload capabilities
The driver advertised VLAN offload unconditionally, even when the PF
did not grant it, as observed with an E835 VF under Hyper-V. This
tells the stack to rely on hardware tag insertion and sends the PF
unsupported VLAN filter requests.
Advertise hardware VLAN tagging and filtering only when GET_VF_RESOURCES
grants the legacy VLAN capability. Do not allocate filter shadow entries
or send ADD_VLAN/DEL_VLAN requests without that capability. Retain VLAN
MTU and checksum/TSO support for software-tagged packets.
Keep advertised capabilities stable across resets, since existing VLAN
interfaces may already rely on them. If resource rediscovery removes
previously advertised VLAN offload, leave the VF stopped and require
reattachment rather than resume with a stale offload contract. A newly
granted capability is not exposed until reattach.
Sponsored by: BBOX.io
[2 lines not shown]
iavf: Reconcile VLAN filters with acknowledged requests
Track desired and acknowledged VLAN membership separately. Retain
pending deletions and uncertain state after failed requests instead of
losing the work when a message is submitted. Make repeated registration
idempotent.
Adapt DPDK's synchronous, single-VID virtchnl request shape and the
bounded desired-state reconciliation used by igbv and ixv. Serialize
VLAN requests under the existing virtchnl mutex, with filter-list
changes under the iflib context lock. Preserve an unresolved
transaction so a late reply cannot be mistaken for a newer operation,
including after the desired state changes.
Reconcile live membership changes without restarting healthy queues.
Limit each pass to 32 requests and a one-second reply deadline,
continuing live batches from the admin task. Down or recovering VFs
apply desired state at initialization; initialization batches continue
through the existing retry callout without rediscovering the mailbox or
[15 lines not shown]
iavf: Handle queue disable during reset recovery
Some PFs reject a redundant DISABLE_QUEUES request after queues have
already stopped. The historical driver retried the request but
continued. The mailbox recovery change instead treated this NACK as a
transport failure, tore down the Admin Queue without a VF reset, and
could not recover the interface during API rediscovery.
Track a PF's pre-reset warning separately from an observed reset and
from exclusive ownership of polled AdminQ replies. RESET_IMPENDING
leaves asynchronous AdminQ processing available so a concurrent stop
can consume its DISABLE_QUEUES reply. VC_POLLING protects VERSION and
GET_VF_RESOURCES rediscovery without blocking that reply. Record
completed resets so subsequent stop/init operations do not issue a
redundant queue-disable request.
If queue disable is not confirmed, wait for an observed reset or request
a VF reset and wait for completion. Give queue shutdown a separate
60-second monotonic deadline to accommodate slow PF reset recovery.
[22 lines not shown]
ice: Use the absolute VF number when adding a VSI
The Add VSI AdminQ command requires an absolute hardware VF number, while
vsi->vf_num is relative to its PF. Add the PF's vf_base_id, as the VF Tx
queue context already does.
On an E810 PF with vf_base_id 128, relative VFs 0 and 1 were associated
with hardware VFs 0 and 1 instead of 128 and 129. Their receive queues
became blocked and both native iavf and DPDK receivers dropped traffic.
A PF whose VF base is zero hides the error.
Validated the VSI-to-function mapping and receive traffic on that PF,
including VF reset recovery and local PF/VF forwarding with VSI loopback
enabled.
Fixes: bc761988b724 ("ice: Add host SR-IOV support")
Sponsored by: BBOX.io
(cherry picked from commit cbaf3f1bc55524126182f63d09ed79ba8cf61cf2)
ice: Allow VSI loopback in VEB mode
The embedded switch installs local forwarding rules with loopback enabled,
but their source VSI must also permit loopback. Without that permission,
traffic between host-attached VFs can trigger Tx data MDD events instead
of reaching the destination VSI.
Set ICE_AQ_VSI_SW_FLAG_ALLOW_LB when initializing a VSI in VEB mode, matching
the forwarding rules to the VSI permission. Keep MAC anti-spoof checking
enabled.
Validated on E810 with native iavf and DPDK VFs, together with the absolute
VF number correction. Local forwarding and queue/reset recovery passed;
spoofed source MACs were still rejected and isolated.
Fixes: bc761988b724 ("ice: Add host SR-IOV support")
Sponsored by: BBOX.io
(cherry picked from commit 9bd865a67c22aa19c99aaee58fd98c03c5ac0bab)
ice: Restart disabled VF Tx queues from saved configuration
DPDK iavf's per-queue stop/start operations send DISABLE_QUEUES followed
by ENABLE_QUEUES without another CONFIG_VSI_QUEUES. Disabling an ice Tx
queue removes its hardware scheduler leaf, so acknowledging ENABLE alone
cannot restart it. Clearing the configured bitmap also prevents the VF
from requesting this sequence.
Track saved configuration separately from active Tx queues. Retain ring
parameters and queue handles on disable, and recreate only the selected
inactive queues on enable. Share the existing Tx context builder between
initial VSI configuration and per-queue restart. Keep the initial
Tx-at-CONFIG behavior and the existing dense-prefix CONFIG validation.
Track cleanup progress per queue and publish valid configuration only
after both Tx and Rx configuration succeed. If an enable fails, undo its
partial setup before permitting a retry. Retain hardware ownership when
cleanup fails and reject another enable of that queue rather than
silently acknowledging it. A failed post-add rollback without a software
[13 lines not shown]
ice: Roll back Tx queues after scheduler setup failures
Add Tx LAN Queues commits the PQM queue and PSM leaf before returning
success. ice_ena_vsi_txq() can subsequently fail to create the software
scheduler node or replay its saved bandwidth configuration. Returning
at that point leaves an allocated queue that the caller does not record.
Later queue setup can fail until a function or PF reset removes it.
Issue Disable Tx LAN Queues directly from the completed Add response
before returning a post-add error. Keep the rollback buffer on the
stack so the allocation failure being recovered cannot also prevent
cleanup. Remove any software node and invalidate its queue context only
after firmware accepts the disable. Preserve the queue context and any
software node when rollback fails so active hardware state is not
hidden.
This follows the Add and Disable command lifecycle documented in the
Intel E810 Datasheet, document 613875-003, section 10.5.5.8.
[4 lines not shown]
iavf: Report the programmed VF RSS configuration
Implement the iflib RSS key and hash query methods for register-based
and PF-managed RSS. Cache the programmed key and HENA selections so hn
can synchronize its synthetic RSS configuration with the VF without
reading hardware or issuing mailbox requests from the query path.
For PF-managed RSS, publish the snapshot only after successful replies
to both CONFIG_RSS_KEY and SET_RSS_HENA. Failed sends, rejected requests,
and missing replies leave it unavailable. Protect the snapshot with
vc_mtx and invalidate it at init, stop, mailbox loss, and reset
notification. Gate queries with the existing running, reset, and mailbox
state.
Report the first 40 key bytes used by standard IPv4/IPv6 tuples, or the
shorter key length supplied by the PF. Preserve register byte order and
report the merged HENA on the direct-programming path. Translate the six
representable IPv4/IPv6 TCP/UDP selections without treating fragment
PCTYPEs as IPv6 extension-header selections. The single-queue register
[10 lines not shown]
Correct some nits in the prior commit (de6328af0c8c)
- Remove unnecessary casts.
- Use the right printf qualifier (%z is for *`size_t`; %j is for
*`maxint_t`). I was mixing up `off_t` in my head.
MFC after: 1 week
Noted by: des (IRC)
Fixes: de6328af0c8c ("tests/sys/kern/ssl_sendfile: :eagain_vs_eof: ...")
tests: Add test for vn_io_fault1 bug
This bug was fixed in b487aca48535, but I did not have a regression
test ready for it at the time.
The test allocates a large buffer, faults part of it in and leaves the
rest unmapped, then tries to read a 3 GiB file into it. If the bug is
present, the read succeeds, but the return value exceeds the requested
amount by exactly one page less than the amount that was prefaulted.
PR: 298159
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D61475
mlx5en: Report the configured RSS tuple selections
Derive SIOCGIFRSSHASH's TCP and UDP selections from the same boot-time
hash configuration used by mlx5e_build_tir_ctx(). The query previously
advertised all six IPv4/IPv6 hash types even when the transport-specific
TIRs selected only the IP addresses. In particular, the default RSS
configuration disables UDP four-tuple hashing.
Continue reporting IPv4 and IPv6 two-tuple hashing unconditionally,
matching the driver's IP-only TIRs. Do not report IPv6 extension-header
variants which the query did not previously claim. Leave key selection,
TIR programming, and the receive datapath unchanged. This lets consumers
such as hn(4) match the VF's hash inputs instead of enabling incompatible
UDP four-tuple hashes on their own receive path.
Fixes: a00718e1dfcd ("Implement SIOCGIFRSSKEY and SIOCGIFRSSHASH and mlx5en(4).")
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59807
(cherry picked from commit 0f111a802f6beb88f3edad9fa48d3721f8b3ec7b)
