DEFINE_ALLOC_MR became unconditionally true, but it isn't used anywhere
now. Several places depended upon DEFINE_IB_FAST_REG, but that is now
always false.
Similarly DEFINE_IB_UMEM_WITH_CHUNK became always false/undefined.
DEFINE_IB_AH_ATTR_WITH_DMAC is now unconditionally true.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/603
Differential Revision: https://reviews.freebsd.org/D35560
NIC input errors have traditionally indicated problems at the link
level (crc errors, runts, etc). People tend to build monitoring
infrastructure around such errors in order to monitor for bad network
hardware. When L3/L4 checksum errors are included in the category of
input errors, it breaks such monitoring, as these errors can originate
anywhere on the internet, and do not necessarily indicate faulty
local network hardware.
Reviewed by: erj, glebius
Differential Revision: https://reviews.freebsd.org/D38346
Sponsored by: Netflix
Jumping direct to ret was not restoring the saved value of x19 and was
also not adjusting sp to discard the two saved registers.
Reviewed by: andrew
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D37922
This patch does remaining enablement in hyperv vpci driver to work
on arm64 Hyper-V. For that it required to use PCI protocol 1.4 and
corresponding different PCI message handling. Also new MSI allocation,
MSI-X mapping, release.
This is the last patch of total three patches to enalbe Hyper-V vPCI
support in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37958
This is enabling the PCI protocol 1.4 and corresponding structures
in order to support arm64 Hyper-V.
This is the 2nd of the three patches to enable Hyper-V vPCI support
in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37780
Summary:
Keep TOEDEV() macro for backwards compatibility, and add a SETTOEDEV()
macro to complement with the new accessors.
Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D38199
To allow device drivers to call into SMCCC we need to initialise it
earlier. As it depends on PSCI, and that is detected via ACPI or FDT
move the call to smccc_init to the PSCI driver.
Add a function for drivers to read the smccc version, or 0 if smccc
is not present.
`SZ_2K` and `SZ_1G` were defined in irdma. They are removed from this
driver.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38150
This is useful to the DRM drivers to let them know if a device is
effectively used by the console.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38089
Overview:
Intel(R) QuickAssist Technology (Intel(R) QAT) provides hardware
acceleration for offloading security, authentication and compression
services from the CPU, thus significantly increasing the performance and
efficiency of standard platform solutions.
This commit introduces:
- Intel® 4xxx Series platform support.
- QuickAssist kernel API implementation update for Generation 4 device.
Enabled services: symmetric cryptography and data compression.
- Increased default number of crypto instances in static configuration
for performance purposes.
OCF backend changes:
- changed GCM/CCM MAC validation policy to generate MAC by HW
and validate by SW due to the QAT HW limitations.
Patch co-authored by: Krzysztof Zdziarski <krzysztofx.zdziarski@intel.com>
Patch co-authored by: Michal Jaraczewski <michalx.jaraczewski@intel.com>
Patch co-authored by: Michal Gulbicki <michalx.gulbicki@intel.com>
Patch co-authored by: Julian Grajkowski <julianx.grajkowski@intel.com>
Patch co-authored by: Piotr Kasierski <piotrx.kasierski@intel.com>
Patch co-authored by: Adam Czupryna <adamx.czupryna@intel.com>
Patch co-authored by: Konrad Zelazny <konradx.zelazny@intel.com>
Patch co-authored by: Katarzyna Rucinska <katarzynax.kargol@intel.com>
Patch co-authored by: Lukasz Kolodzinski <lukaszx.kolodzinski@intel.com>
Patch co-authored by: Zbigniew Jedlinski <zbigniewx.jedlinski@intel.com>
Sponsored by: Intel Corporation
Reviewed by: markj, jhb
Differential Revision: https://reviews.freebsd.org/D36254
Right now we have little visibility into packet drops within netmap.
Start trying to make packet loss issues more visible by counting queue
drops in the transmit path, and in the input path for interfaces running
in emulated mode, where we place received packets in a bounded software
queue that is processed by rxsync.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38064
The check is ok by default, since the default value of
netmap_generic_ringsize is 1024. But we should check against the
configured "ring" size.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38062
Per the removed comments these fields should be loaded only once, since
they can in principle be modified concurrently, though this would be a
violation of the userspace contract with netmap.
No functional change intended.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38061
The code paths while dumping do not got through busdma. As such,
safeguard against calling bus_dmamap_sync() with a NULL map. The x86
implementation tolerates this but others do not, resulting in a
NULL dereference panic when dumping to a vtblk device on arm64, riscv,
etc.
Fixes: 782105f7c8 ("vtblk: Use busdma")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37990
Add in the zones for my MacbookAir6,2, a 2013 Macbook Air.
Tested - said Macbook Air 2013. Thermal Zones and keyboard backlight
control works fine.
Differential Revision: https://reviews.freebsd.org/D38073
Approved by: jrtc27
We need to repeat the operation if the vnode was relocked.
Reported and reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38114
Some devices have CDC_CM descriptors that would point us to
the wrong interfaces. Add a quirk to ignore those (prefering the
CDC_UNION descriptor effectively)
Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37942
Add ACPI_RESOURCE_TYPE_FIXED_MEMORY32 to the PCI ECAM driver. This is
used on the Microsoft Dev Kit 2023 and reportedly the Lenovo x13s.
Reviewed by: Robert Clausecker <fuz@fuz.su> (Earlier version)
Tested by: Robert Clausecker <fuz@fuz.su> (Earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D38031
In case the reset sequence fails (ena_destroy_device() followed by
ena_restore_device() calls) during ena_restore_device(), the driver
resources are being freed. After the clean-up, the timer service is
re-armed in order to try and re-initialize the driver state.
But, such an attempt would fail given that the resources are freed.
Moreover, this would actually cause either the system to fail or a
panic.
When the driver fails in ena_restore_device() procedure, the only
recovery is either unloading and loading the driver or instance
reboot.
This change removes the timer service re-arm in case of failure
in ena_restore_device().
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
Fixes: 78554d0c70 ("ena: start timer service on attach")
Commit [1] first added the ena_tx_buffer.print_once member,
so that a message about a missing tx completion is printed only
once per packet (and not every second when the watchdog runs).
In this commit print_once is initialized to true, and is set back
to false after detecting a missing tx completion and printing
a warning about it to dmesg.
Commit [2] incorrectly reverses the values assigned to print_once.
The variable is initialized to be true but is checked to be false
when a missing tx completion is detected. This is never true, and
therefore the warning print for each missing tx completion is never
printed since this commit.
Commit [3] added time passed since last TX cleanup to the missing
tx completions per-packet print. However, due to the issue in commit
[2], this time is never printed.
This commit reverses back the values assigned to ena_tx_buffer.print_once
erroneously by commit [2], bringing back to life the missing tx
completion per-packet print.
Also add a space after "." in the missing tx completion print.
[1] - 9b8d05b8ac ("Add support for Amazon Elastic Network Adapter (ENA) NIC")
[2] - 74dba3ad78 ("Split function checking for missing TX completion in ENA driver")
[3] - d8aba82b5c ("ena: Store ticks of last Tx cleanup")
Fixes: 74dba3ad78 ("Split function checking for missing TX completion in ENA driver")
Fixes: d8aba82b5c ("ena: Store ticks of last Tx cleanup")
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
To attach to the hypervisor, kvmclock needs to write a per-CPU MSR.
When EARLY_AP_STARTUP is not defined, device attach happens too early:
APs are not yet spun up, so smp_rendezvous only runs the callback on the
local CPU. As a result, the timecounter only gets initialized on the
BSP, and then timekeeping is broken on SMP systems.
Implement handling for !EARLY_AP_STARTUP kernels: keep track of the CPU
on which device attach ran, and then use a SI_SUB_SMP SYSINIT to
register the rest of the CPUs with the hypervisor.
Reported by: Shrikanth R Kamath <kshrikanth@juniper.net>
Reviewed by: kib, jhb (earlier versions)
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D37705
Virtio operates with physical addresses, while busdma is designed to
map these to produce bus addresses. On most supported platforms,
these two are interchangeable; on powerpc platforms, they are not.
When on powerpc, set an IOMMU of NULL, which causes the powerpc busdma
code to bypass the iommu mapping; this leaves us with the physical
buffer addresses which the virtio host expects to see.
Tested by: alfredo
Fixes: 782105f7c8 ("vtblk: Use busdma")
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D37891
The Windows Dev Kit 2023 has an if_ure NIC with custom vendor and
procuct IDs. Add them to the driver.
Tested by: Robert Clausecker <fuz@fuz.su>
Obtained from: OpenBSD
Sponsored by: Arm Ltd
Formatting string for uint64_t has portablity issue and
lead bulid breakage, so fix it.
Reviewed by hrs
Differential Revision: https://reviews.freebsd.org/D37937
Simply said, WDAT is an abstraction for the real WDT hardware. For
instance, to add a newer generation WDT to ichwd(4), one must know the
detailed hardware registers, etc..
With WDAT, the necessary IO accesses to operate the WDT are comprehensively
described in it and no hardware knowledge is required.
With this driver, the WDT on Advantech ARK-1124C, Dell R210 and Dell R240 are
detected and operated flawlessly.
* While R210 is also supported by ichwd(4), others are not supported yet.
The unfortunate thing is that not all systems have WDAT defined.
Submitted by: t_uemura at macome.co.jp
Reviewed by: hrs
Differential Revision: https://reviews.freebsd.org/D37493
IFCAP2_XXX constants are integers, they do not need shift for the
definition. But their usage as bitmask for if_capenable2 does require
shift. Add convenience macro IFCAP2_BIT() for consumers.
Fix the only existing consumer, mlx5(4) RXTLS enable bits.
Reported by: jhb
Reviewed by: jhb, jhibbits, hselasky
Coverity CID: 1501659
Sponsored by: NVIDIA networking
Differential revision: https://reviews.freebsd.org/D37862
Modern multi-protocol phys are capable of supporting multiple different
protocols. Add a method for mode (and/or its variants) setting.
Discused with: ganbold, manu, andrew
MFC after: 3 weeks
Prior to Conrad's changes to replace session integer IDs with a
pointer to the driver-specific state in commit 1b0909d51a, the
driver had to find the softc pointer from the adapter before it could
locate the ccr_session structure for a completed request. Since
Conrad's changes, the ccr_session pointer can now be obtained directly
from the crp. Add a backpoint from ccr_session back to ccr_softc and
use this in place of the ccr_softc member in cxgbe's struct adapter.
Sponsored by: Chelsio Communications
netmap_monitor_stop() called nm_monitor_none() after the head of
the zero-copy monitors had been reset, thus thinking that there
was nothing left to do.
MFC after: 7 days
Netmap users on FreeBSD are not supposed to import code from the
github netmap repository anymore. They should use the code that
is available in the src repo. We can therefore drop the compatibility
code.
MFC after: 7 days
for all devices except Kensington Slimblade Trackball as it brokes
some other devices like Contour Rollermouse Red
Add a quirk for it as well.
Reported by: Atte Peltomäki <koston_AT_iki_DOT_fi>
PR: 267922
MFC after: 2 weeks
for all devices except Kensington Slimblade Trackball as it brokes
some other devices like Contour Rollermouse Red
Add a quirk for it as well.
Reported by: Atte Peltomäki <koston_AT_iki_DOT_fi>
PR: 267922
MFC after: 2 weeks
Change the range test in iommu_gas_match_one from '< ubound' to '<=
ubound', and pass a smaller-by-one ubound parameter to it, to avoid
overflow in ubound calculation.
Reported by: andrew
Reviewed by: andrew (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37764
Historically the ACPI _HID for both the Arm PL011 and Generic UARTs
was ARMH0011. In the Arm Base Boot Requirements 2.0 the Generic UART
_HID is changed to ARMHB000. Use this new value in the PL011 driver
where we support both UART types.
This has been observed in some recent EDK2 builds.
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink DMC-620
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
The SPDX-License-Identifier was wrong in the Arm CoreLink CMN-600
driver files. It used the incorrect FreeBSD variant of the BSD-2-Clause
identifier. According to [1] all files should use BSD-2-Clause.
[1] https://tools.spdx.org/app/check_license/
Reported by: emaste
Sponsored by: Arm Ltd
In 0a9a4d2cd6 a check for OPT_ACPI was added to the hwpmc Makefile
to fix loading the module in a kernel where ACPI has been disabled.
This broke loading the module when ACPI was enabled in the build as
OPT_ACPI isn't a Makefile macro so was always disabled.
Move this check to the C files where the DEV_ACPI macro does exist.
Reviewed by: gnn
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D37773
This is to upgrade current irdma driver version (in support of RDMA on
Intel(R) Ethernet Controller E810) to 1.1.5-k
change summary:
- refactor defines for hardware registers
- rereg_mr verb added in libirdma
- fix print warning during compilation
- rt_ros2priority macro fix
- irdma.4 validated with mandoc
- fixing nd6_resolve usage
- added libirdma_query_device
- sysctl for irdma version
- aeq_alloc_db fix
- dwork_flush protected with qp refcount
- PFC fixes
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
Sponsored by: Intel Corporation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36944
mrsas_issue_blocked_cmd stores a pointer to an on-stack variable
in its softc so that the driver can call wakeup() on the correct
pointer. Once the loop around tsleep() has finished however, the
pointer is no longer needed and any further use would be invalid.
Clear sc->chan to NULL after the loop.
Reported by: GCC -Wdangling-pointer
Differential Revision: https://reviews.freebsd.org/D37628
In some drivers we need to assert and deassert a group of hardware
resets in any order. To support this add a new hwreset_array that
manages all hwresets defined for a device.
Reviewed by: bz, manu, mmel
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37357
The SCMI specification describes a set of standard interfaces for power,
performance and system management.
SCMI is extensible and provides interfaces to access functions which are
often implemented in firmwares in the System Control Processor (SCP).
This implements Shared Memory-based transfer, which is one of the ways on
how messages are exchanged between agents and the platform.
This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which
is a mechanism that the caller can use to alert the callee of the presence
of a message.
The support implements clock management interface. For instance this allows
us to control HDMI pixel clock on ARM Morello Board.
Tested on ARM Morello Board.
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D37316
Reviewed by: manu
Sponsored by: UKRI
Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver
includes obfuscated source, and has reported potential security issues.
Differential Revision: https://reviews.freebsd.org/D33468
Sync serial (e.g. T1/T1/G.703) interfaces are obsolete, this driver
includes obfuscated source, and has reported potential security issues.
Differential Revision: https://reviews.freebsd.org/D33467
And the related sconfig utility. Sync serial (e.g. E1/T1) interfaces
are obsolete, and nobody responded to several inquires on the mailing
lists about use of these drivers.
Relnotes: Yes
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23928
* Add link-state change notifications by subscribing to ifnet_link_event.
In the Linux netlink model, link state is reported in 2 places: first is
the IFLA_OPERSTATE, which stores state per RFC2863.
The second is an IFF_LOWER_UP interface flag. As many applications rely
on the latter, reserve 1 bit from if_flags, named as IFF_NETLINK_1.
This flag is mapped to IFF_LOWER_UP in the netlink headers. This is done
to avoid making applications think this flag is actually
supported / presented in non-netlink outputs.
* Add flag change notifications, by hooking into rt_ifmsg().
In the netlink model, notification should include the bitmask for the
change flags. Update rt_ifmsg() to include such bitmask.
Differential Revision: https://reviews.freebsd.org/D37597
For the TCP protocol inpcb storage specify allocation size that would
provide space to most of the data a TCP connection needs, embedding
into struct tcpcb several structures, that previously were allocated
separately.
The most import one is the inpcb itself. With embedding we can provide
strong guarantee that with a valid TCP inpcb the tcpcb is always valid
and vice versa. Also we reduce number of allocs/frees per connection.
The embedded inpcb is placed in the beginning of the struct tcpcb,
since in_pcballoc() requires that. However, later we may want to move
it around for cache line efficiency, and this can be done with a little
effort. The new intotcpcb() macro is ready for such move.
The congestion algorithm data, the TCP timers and osd(9) data are
also embedded into tcpcb, and temprorary struct tcpcb_mem goes away.
There was no extra allocation here, but we went through extra pointer
every time we accessed this data.
One interesting side effect is that now TCP data is allocated from
SMR-protected zone. Potentially this allows the TCP stacks or other
TCP related modules to utilize that for their own synchronization.
Large part of the change was done with sed script:
s/tp->ccv->/tp->t_ccv./g
s/tp->ccv/\&tp->t_ccv/g
s/tp->cc_algo/tp->t_cc/g
s/tp->t_timers->tt_/tp->tt_/g
s/CCV\(ccv, osd\)/\&CCV(ccv, t_osd)/g
Dependency side effect is that code that needs to know struct tcpcb
should also know struct inpcb, that added several <netinet/in_pcb.h>.
Differential revision: https://reviews.freebsd.org/D37127
When PCI_IOV is not enabled, do not attempt to call
iflib_softirq_alloc_generic(...IFLIB_INTR_IOV), as it results
in boot-time warnings similar to:
taskqgroup_attach_cpu: qid not found for iov cpu=2
ixl2: taskqgroup_attach_cpu failed 22
Instead, make it conditional on PCI_IOV like the other
SR-IOV related code.
Reviewed by: erj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37609
Add a PNP macro in order to load this driver automatically.
While here check if the device is enabled in DT before probing it.
Reviewed by: wma
Sponsored by: Alstom
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D37579
Use correct resolution by compat table. If dtb is not defined use default 9 bit mode.
11 bit detection is called if 9 bit mode is used.
Sysctl resolution variable is added to change resolution in case.
Some sensors didn't pull ACK while reading from nonexistent registers and it caused I2C
read error and detect failure, so now detect failure does not cause driver break.
Obtained from: Semihalf
Sponsored by: Alstom
Differential revision: https://reviews.freebsd.org/D37497
Current Xen Processor driver will evaluate any Processor object on the
ACPI tables regardless of whether the processor is online or not.
Avoid doing so for processors that are not online, as evaluating
methods of processors that are not online could lead to accesses to
invalid memory, and in any case the data that the driver fetches from
the Processor ACPI object only makes sense for processors that are
online.
Note the CPU related data fetched from Xen using XENPF_get_cpuinfo
hypercall could be cached, I leave that as a future optimization.
Sponsored by: Citrix Systems R&D
Fixes: b93f47eaee ('xen/acpi: upload Cx and Px data to Xen')
BUS_PASS_SUPPORTDEV is semantically better than BUS_PASS_RESOURCE, since
it's a support device for dtsec, so only needs probed before dtsec, not
before interrupts.
Suggested by: manu
It's possible the MDIO device hasn't been and attached, or is incorrect
in the device tree so can't probe and attach. In this case,
ofw_bus_find_child_device_by_phandle() will fail, and return NULL.
Return an error from find_mdio() here to prevent the MAC from attaching,
rather than worry about a NULL pointer dereference later on when
accessing the PHY.
Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold
which specifies a temperature above which a system should transition
to the S3 standby state.
On FreeBSD, this is more useful than _HOT, which specifies the S4
transition threshold temperature (since FreeBSD does not generally
support the S4 state), or, in many cases, _CRT, since after
transitioning to S3 the system can cool and then be resumed.
Reviewed by: jhb, bcr (manpages)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D35980
of various keyboard drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
Keyboard grabbing is disabled in KDB and during panics.
MFC with: 4a0db5e292
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
of psm(4), ums(4) and sysmouse(4) drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
MFC after: 2 weeks
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
We shouldn't force USB2 only based on if we have an external PHY.
The internal PHY register tell us what link speed we can acheive
and we need to force USB2 only if it cannot do USB3.
This is only available after revision 0x290A of the dwc3 IP.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37394
Fixed: 1331c0f44b ("Add support for RockChip RK356X to DWC3 driver.")
Sponsored by: Beckhoff Automation GmbH & Co. KG
We need to enable some quirks based on the version so read it.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37393
Sponsored by: Beckhoff Automation GmbH & Co. KG
Usually dwc3 needs a glue node that contain the SoC specific clocks/resets.
For some reason the RK3328 DTS doesn't have this glue node and the clocks
are specified in the dwc3 node directly.
The bindings says that it is allowed but doesn't specified some strict names
for them.
Add a specific case for RK3328 based on the compatible string.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37392
Sponsored by: Beckhoff Automation GmbH & Co. KG
Rather than requiring a socket to be created as a TLS socket from the
get go, switch a TOE socket from "plain" TOE to TLS mode when a
receive key is added to the socket.
The firmware is only able to switch a "plain" TOE connection to TLS
mode if the head of the pending socket data is the start of a TLS
record, so the connection is migrated to TLS mode as a multi-step
process.
When TOE TLS RX is enabled, the associated connection's receive side
is frozen via a flag in the TCB. The state of the socket buffer is
then examined to determine if the pending data in the socket buffer
ends on a TLS record boundary. If so, the connection is migrated to
TLS mode and unfrozen. Otherwise, the connection is unfrozen
temporarily until more data arrives. Once more data arrives, the
receive queue is frozen again and rechecked. This continues until the
connection is paused at a record boundary. Any records received
before TLS mode is enabled are decrypted as software records.
Note that this removes the 'rx_tls_ports' sysctl. TOE TLS offload for
receive is now enabled automatically on existing TOE connections when
using a KTLS-aware SSL library just as it was previously enabled
automatically for TLS transmit. This also enables TLS offload for TOE
connections which enable TLS after passing initial data in the clear
(e.g. STARTTLS with SMTP).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D37351
Currently bhyve's NVMe controller cannot save feature values cross
reboot. It should return a FEATURE_NOT_SAVEABLE error when the command
specifies a save flag.
Quote from NVMe specification, page 205:
https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf
If the Feature Identifier specified in the Set Features command is not
saveable by the controller and the controller receives a Set Features
command with the Save bit set to one, then the command shall be aborted
with a status of Feature Identifier Not Saveable.
Reviewed by: chuck (older version)
Approved by: manu (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32767
Intel 82599 has errata related to IPv4 UDP frames with zero checksum.
It reports such datagrams with L4 integrity errors in IXGBE_XEC
register. And after afb1aa4e6d commit such errors are reported
via IFCOUNTER_IERRORS. This confuses users, since actually all frames
are handled correctly by the system.
To workaround the problem, let's ignore the XEC register value for
82599 cards for now.
PR: 266048
Discussed with: erj
MFC after: 1 week
Sponsored by: Yandex LLC
The previous commit lost an implicit struct socket * cast. Use an
inline function instead as the macro is already rather long.
Fixes: e1401f7579 cxgbe: use standard sototcpcb() accessor macro to get socket's tcpcb
Sponsored by: Chelsio Communications
In addition to (*func) tasklet also seems to have a (*callback) with
a different argument. Add support for this and add tasklet_setup()
as well for support in more drivers.
The from_tasklet() definition is duplicated in the tree; hide it there
under #ifndef to avoid a re-definition. People should generally add
LinuxKPI bits to linuxkpi rather than private files if they also rely
on other LinuxKPI bits.
X-MFC: DO NOT MFC, space allocated by drivers not us.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37216
Polarity inversion register was mistekanly filled with the value of
the direction configuration register.
Correct that.
Reviewed by: kd
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D37262
These values come from section 7.7.11 ("ACS Extended Capability") of the
PCI Express Base Specification Revision 6.0, dated 16 Dec 2021.
MFC after: 1 week
Sponsored by: Chelsio Communications
Reviewed by: kib@
Differential Revision: https://reviews.freebsd.org/D37270
If fman_init() fails it can leave things in a state where it cannot
attach at all in the future, because it would simply exit without
tearing down everything that was already set up. Go to the exit point
to clean up on error instead, so that it can try again later.
MFC after: 1 week
Added support for application management interface. There are two types of commands supported:
1. Firmware IOCTLs: These ioctls are meant for firmware
consumption. Driver acts as a transport for these.
2. Driver only IOCTLs: These ioctls are meant for driver
consumption. Driver will serve these ioctls without sending them down
to firmware.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36448
Fixed the issue when kernel invokes _init() when it is already in
_init() state by invoking _stop() in such case.
Reviewed by: imp
Differential Revsion: https://reviews.freebsd.org/D36445
Removed sysctl node vlan_only which is not being used after migrating
from l2_set_rx_mask to l2_filter_alloc.
Reviewed by: imp
Differential Revsion: https://reviews.freebsd.org/D36444
Added support for Thor controller.
Below are the supported operations:
1. IPv4 ping (ICMP)
2. iperf / netperf (IPv4 TCP)
3. Promiscuous (tcpdump)
4. Can achieve 20 Gbps on a 25 G link (Uni-Di)
5. Can achieve 60 Gbps on a 100 G link (Uni-Di)
6. Port level and queue level driver stats.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36438
This is preparatory patch for making a base for Broadcom's Thor
controller support. It converts all doorbell writes into function
pointers.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36437
Updates the drivers to Broadcom's latest:
HWRM Version 1.10.2.34 using HSI definition version 1.8.4
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36436
There's been a report recently of mbufs with data that crosses a page
boundary. It seems those mbufs are generated by the iSCSI target
system:
https://lists.xenproject.org/archives/html/xen-devel/2021-12/msg01581.html
In order to handle those mbufs correctly on netfront use the bus_dma
interface and explicitly request that segments must not cross a page
boundary. No other requirements are necessary, so it's expected that
bus_dma won't need to bounce the data and hence it shouldn't
introduce a too big performance penalty.
Using bus_dma requires some changes to netfront, mainly in order to
accommodate for the fact that now ring slots no longer have a 1:1
match with mbufs, as a single mbuf can use two ring slots if the data
buffer crosses a page boundary. Store the first packet of the mbuf
chain in every ring slot that's used, and use a mbuf tag in order to
store the bus_dma related structures and a refcount to keep track of
the pending slots before the mbuf chain can be freed.
Reported by: G.R.
Tested by: G.R.
MFC: 1 week
Differential revision: https://reviews.freebsd.org/D33876
Now that vtblk uses busdma, it keeps important information inside its
request structures. The functions used for kernel dumps synthesize
their own request structures rather than using structures initialized
with the necessary bits for busdma.
Add busdma-bypass paths. Since dumping writes contiguous blocks of
physical memory, vtblk doesn't need busdma in that case.
Reported by: glebius
Tested by: glebius
Differential Revision: https://reviews.freebsd.org/D37243
vcpuHint has been expanded to 16 bit on host side to enable
interruptions to be routed to more CPUs. Guest side should align with
the change.
This change has been tested with hosts with 8-bit and 16-bit vcpuHint,
on both platforms host side can get correct value.
This driver is for ESXi product which only supports x86/x64. They are
little-endian. So there is no need to consider big-endian system.
PR: 264840
Reviewed by: imp@, Zhenlei Huang
The ipmi watchdog pretimeout action can trigger unintentionally in
certain rare, complicated situations. What we have seen at Netflix
is that the BMC can sometimes be sent a continuous stream of
writes to port 0x80, and due to what is a bug or misconfiguration
in the BMC software, this results in the BMC running out of memory,
becoming very slow to respond to KCS requests, and eventually being
rebooted by its own internal watchdog. While that is going on in
the BMC, back in the host OS, a number of requests are pending in
the ipmi request queue, and the kcs_loop thread is working on
processing these requests. All of the KCS accesses to process
those requests are timing out and eventually failing because the
BMC is responding very slowly or not at all, and the kcs_loop thread
is holding the IPMI_IO_LOCK the whole time that is going on.
Meanwhile the watchdogd process in the host is trying to pat the
BMC watchdog, and this process is sleeping waiting to get the
IPMI_IO_LOCK. It's not entirely clear why the watchdogd process
is sleeping for this lock, because the intention is that a thread
holding the IPMI_IO_LOCK should not sleep and thus any thread
that wants the lock should just spin to wait for it. My best guess
is that the kcs_loop thread is spinning waiting for the BMC to
respond for so long that it is eventually preempted, and during
the brief interval when the kcs_loop thread is not running,
the watchdogd thread notices that the lock holder is not running
and sleeps. When the kcs_loop thread eventually finishes processing
one request, it drops the IPMI_IO_LOCK and then immediately takes the
lock again so it can process the next request in the queue.
Because the watchdogd thread is sleeping at this point, the kcs_loop
always wins the race to acquire the IPMI_IO_LOCK, thus starving
the watchdogd thread. The callout for the watchdog pretimeout
would be reset by the watchdogd thread after its request to the BMC
watchdog completes, but since that request never processed, the
pretimeout callout eventually fires, even though there is nothing
actually wrong with the host.
To prevent this saga from unfolding:
- when kcs_driver_request() is called in a context where it can sleep,
queue the request and let the worker thread process it rather than
trying to process in the original thread.
- add a new high-priority queue for driver requests, so that the
watchdog patting requests will be processed as quickly as possible
even if lots of application requests have already been queued.
With these two changes, the watchdog pretimeout action does not trigger
even if the BMC is completely out to lunch for long periods of time
(as long as the watchdogd check command does not also get stuck).
Sponsored by: Netflix
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36555
In non-Hyper-V systems during Hyper-V initialization, system
initialization was getting hung, as hyperv_identify(),
was returning successful irrespective of the type of the platform.
Reviewed by: andrew, whu
Fixes: 9729f076e4
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37219
Assertions suggest that the loop in iommu_gas_fini_domain is executed
zero times, so remove it.
Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D37204
Maintain a pointer to an element in the domain map that is left of any
sufficiently large free gap in the tree and start the search for free
space there, rather than at the root of the tree. On find_space, move
that pointer to the leftmost leaf in the subtree of nodes with
free_down greater than or equal to the minimum allocation size before
starting the search for space from that pointer. On removal of a node
with address less than that pointer, update that pointer to point to
the predecessor or successor of the removed node.
In experiments with netperf streaming, this reduces by about 40% the
number of map entries examined in first-fit allocation.
Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36624
This commit brings back the driver from FreeBSD commit
f187d6dfbf plus subsequent fixes from
upstream.
Relative to upstream this commit includes a few other small fixes such
as additional INET and INET6 #ifdef's, #include cleanups, and updates
for recent API changes in main.
Reviewed by: pauamma, gbe, kevans, emaste
Obtained from: git@git.zx2c4.com:wireguard-freebsd @ 3cc22b2
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36909
When flushing the UART, we need to drain manually if LSR_TEMT is
*not* asserted, aka. if the transmit FIFO is not empty.
Reported by: void <void@f-m.fm>
Fixes: c4b68e7e53 "ns8250: Check if flush via FCR succeeded"
Differential Revision: https://reviews.freebsd.org/D37185
- We depend on header polution to include sys/malloc.h. Include it
directly.
- Only define FDT-specific fuctions when building a FDT kernel.
Sponsored by: Innovate UK
This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.
Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744
psci_attach is way too late to provide the intended semantics for
psci_present. psci calls can be made immediately after psci_init(),
called way earlier at SI_SUB_CPU + SI_ORDER_FIRST, and we need it to
be valid as early as we can possibly call a psci function.
This fixes booting RPi3+4 with the in-review spintable patch;
rpi3-psci-monitor patches the FDT to add a PSCI node, but it doesn't
patch each cpus' enable-method. Because of this, we would stall the
boot while enabling CPU 1 as we saw a valid looking enable-method and
"no" functional PSCI and attempted to use the spintable rather than
simply not starting secondary APs.
Fixes: 2218070b2c ("psci: finish psci_present implementation")
Reported by: karels
Refactor the code to put split the MSR values for x86 and arm64
Hyper-V. Code not yet built. This is one of several patches for
the arm64 Hyper-V enablement.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37103
2782ed8f6c fixed the standalone module
build. REmove the now duplicate includes for opt_acpi.h and
opt_platform.h. Als remove the if_mdio.h again in both the Makefile
and the implementation file as it is not (currently) used.
X-MFC with: ba7319e909
MFC after: 70 days
New driver to ACPI generic event device, defined in ACPI spec.
Some ACPI power button may not work without this.
In qemu arm64 with "virt" machine, with ACPI firmware,
enable devd check devd message by
and invoke following command in qemu monitor
(qemu) system_powerdown
and make sure some power button input event appear.
(setting sysctl hw.acpi.power_button_state=S5 is not work,
because ACPI tree does not have \_S5 object.)
Reviewed by: andrew, hrs
Differential Revision: https://reviews.freebsd.org/D37032
This is the second part of the ARM64 Hyper-V enablement.
These changes here are mostly with Make, release changes and also
changes required in vmbus.c hyperv.c and common files in hyperv.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36467
In ARM64 gen2 Hyper-V, use IRQ resource from vmbus_res, which is owning
the IRQ for current device tree. It allows the MMIO resource to be
successfully allocated for vmbus from parent acpi_syscontainer.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37064
This add BUS_GET_DEVICE_PATH interface,
which shows device tree of openfirm/fdt.
In qemu-system-arm64 with "virt" machine with device-tree firmware,
% devctl getpath OFW cpu0
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37031
The emulated UART in the Firecracker VMM (aka the implementation in the
rust-vmm/vm-superio project) includes FIFOs but does not implement the
FCR register, which is used by ns8250_flush to flush the FIFOs.
Check the LSR to see if there is still data in the FIFOs and call
ns8250_drain if necessary.
Discussed with: emaste, imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36979
We assume that bus addresses from busdma are the same thing as
"physical" addresses in the Virtio specification; this seems to
be true for the platforms on which Virtio is currently supported.
For block devices which are limited to a single data segment per
I/O, we request PAGE_SIZE alignment from busdma; this is necessary
in order to support unaligned I/Os from userland, which may cross
a boundary between two non-physically-contiguous pages. On devices
which support more data segments per I/O, we retain the existing
behaviour of limiting I/Os to (max data segs - 1) * PAGE_SIZE.
Reviewed by: bryanv
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36667
Most virtio_blk requests are launched from vtblk_startio; prior to this
commit, if vtblk_request_execute failed (e.g. due to a lack of space on
the virtio queue) vtblk_startio would requeue the request to be
reattempted later.
Add a flag "vbr_requeue_on_error" to requests and perform the requeuing
from inside vtblk_request_execute instead.
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36665
The error, if any, now gets stashed in the request structure. (Step 1
of reworking this driver to use busdma.)
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36664
The Virtio MMIO bus driver was added in 2014 with support for devices
exposed via FDT; in 2018 support was added to discover Virtio MMIO
devices via ACPI tables, as in QEMU. The Firecracker VMM eschews both
FDT and ACPI, instead presenting device information via kernel command
line arguments of the form virtio_mmio.device=<parameters>.
These command line parameters get converted into kernel environment
variables; this adds support for parsing those variables and attaching
virtio_mmio children to nexus.
There is a case to be made that it would be cleaner to have a new
"cmdlinebus" attached to nexus and virtio_mmio children attached to
that. A future commit might do that.
Discussed with: imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36189
Issue Description:
The RequestCredits field of IOCFacts got changed between the Phase23
firmware to Phase24 firmware. So as part of firmware update operation,
driver has to free the resources & pools which are created with the Phase23
Firmware's IOCFacts data (i.e. during driver load time) and has to
reallocate the resources and pools using Phase24's IOCFacts data. Here
driver has freed the interrupts but missed to reallocate the interrupts and
hence config page read operation is getting timed out and controller is
going for recursive reinit (controller reset) operations and leading to
kernel panic.
Fix:
Reallocate the interrupts if the interrupts are disabled as part of
firmware update/downgrade operation.
Submitted by: Sreekanth Ready <sreekanth.reddy@broadcom.com>
Tested by: ken
MFC after: 3 days
DPAA2 is a hardware-level networking architecture found in some NXP
SoCs which contain hardware blocks including Management Complex
(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O
processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer
pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify an
access to the underlying hardware. Each DPAA2 object has its own
driver (to perform an initialization at least) and will be visible
as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in
order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX)
dpaa2_mcX
dpaa2_rcX
dpaa2_mcp0
...
dpaa2_mcpN
dpaa2_bpX
dpaa2_macX
dpaa2_io0
...
dpaa2_ioM
dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI
and FDT flavours and implements helper interfaces to allocate and
assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some
of the objects as resources for the other DPAA2 objects to let them
function properly). Almost all of the DPAA2 objects are assigned to
the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface
to be operational. It is the most complex object in terms of
dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor)
Tested by: manu, bz
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36638
