sys/modules: MODULES_OVERRIDE takes precedence over EXTRA_MODULES and WITHOUT_MODULES

MODULES_OVERRIDE has traditionally taken precedence over EXTRA_MODULES
and WITHOUT_MODULES as the exact list of

sys/modules: MODULES_OVERRIDE takes precedence over EXTRA_MODULES and WITHOUT_MODULES

MODULES_OVERRIDE has traditionally taken precedence over EXTRA_MODULES
and WITHOUT_MODULES as the exact list of modules to build. Over time,
things have been added that has broken this. Move the .endif that makes
this the case to the right place. The so called 'ALL_MODULES' option is
the only thing with higher precedence, but it's not quite all the
options anymore (though it is much more of them, and doesn't quite
work on !x86).

Sponsored by: Netflix

show more ...

Import the WireGuard driver from zx2c4.com.

This commit brings back the driver from FreeBSD commit
f187d6dfbf633665ba6740fe22742aec60ce02a2 plus subsequent fixes from
upstream.

Relative to upstream

Import the WireGuard driver from zx2c4.com.

This commit brings back the driver from FreeBSD commit
f187d6dfbf633665ba6740fe22742aec60ce02a2 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

show more ...

sys/modules: Catchup to armv[45] being removed

Now that armv[45] are removed, simplify some tests for armv[67] that are
now either always true, or always true when we're on arm.

Sponsored by: Netf

sys/modules: Catchup to armv[45] being removed

Now that armv[45] are removed, simplify some tests for armv[67] that are
now either always true, or always true when we're on arm.

Sponsored by: Netflix

show more ...

sys/modules: Delete now empty if

Ah, the joys of pushing a commit with a dirty editor buffer that all the
checks in git didn't catch... Also, my eyeballs missed it too :(.

Fixes: ba9f71ddeca8
Noti

sys/modules: Delete now empty if

Ah, the joys of pushing a commit with a dirty editor buffer that all the
checks in git didn't catch... Also, my eyeballs missed it too :(.

Fixes: ba9f71ddeca8
Noticed by: jrtc27
Sponsored by: Netflix

show more ...

sys/modules: simplify a little by moving syscons to x86 only

syscons is x86 only now that sparc has been retired. No need for the
extra if. Also alphabetize p2sb.

Sponsored by: Netflix

sys/modules: tidy up a bit by moving _hyperv to aarch64 section

Suggested by: jhb
Sponsored by: Netflix

hyperv: Don't build on 32-bit arm

Sponsored by: Netflix

Stop building FDT-only modules in an ACPI only kernel

When building a kernel without FDT these modules don't build. As they
depend on FDT and don't work with ACPI disable them.

Reviewed by: imp, ke

Stop building FDT-only modules in an ACPI only kernel

When building a kernel without FDT these modules don't build. As they
depend on FDT and don't work with ACPI disable them.

Reviewed by: imp, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37178

show more ...

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
gues

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

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

show more ...

Add initial DPAA2 support

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 D

Add initial DPAA2 support

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

show more ...

netlink: add netlink support

Netlinks is a communication protocol currently used in Linux kernel to modify,
read and subscribe for nearly all networking state. Interfaces, addresses, routes,
firew

netlink: add netlink support

Netlinks is a communication protocol currently used in Linux kernel to modify,
read and subscribe for nearly all networking state. Interfaces, addresses, routes,
firewall, fibs, vnets, etc are controlled via netlink.
It is async, TLV-based protocol, providing 1-1 and 1-many communications.

The current implementation supports the subset of NETLINK_ROUTE
family. To be more specific, the following is supported:
* Dumps:
- routes
- nexthops / nexthop groups
- interfaces
- interface addresses
- neighbors (arp/ndp)
* Notifications:
- interface arrival/departure
- interface address arrival/departure
- route addition/deletion
* Modifications:
- adding/deleting routes
- adding/deleting nexthops/nexthops groups
- adding/deleting neghbors
- adding/deleting interfaces (basic support only)
* Rtsock interaction
- route events are bridged both ways

The implementation also supports the NETLINK_GENERIC family framework.

Implementation notes:
Netlink is implemented via loadable/unloadable kernel module,
not touching many kernel parts.
Each netlink socket uses dedicated taskqueue to support async operations
that can sleep, such as interface creation. All message processing is
performed within these taskqueues.

Compatibility:
Most of the Netlink data models specified above maps to FreeBSD concepts
nicely. Unmodified ip(8) binary correctly works with
interfaces, addresses, routes, nexthops and nexthop groups. Some
software such as net/bird require header-only modifications to compile
and work with FreeBSD netlink.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36002
MFC after: 2 months

show more ...

divert(4): do not depend on ipfw(4)

Although originally socket was intended to use with ipfw(4) only, now
it also can be used with pf(4). On a kernel without packet filters,
it still can be used to

divert(4): do not depend on ipfw(4)

Although originally socket was intended to use with ipfw(4) only, now
it also can be used with pf(4). On a kernel without packet filters,
it still can be used to inject traffic.

show more ...

qat: Move qat_c2xxx firmware files and build glue into separate dirs

Reviewed by: Zdziarski, KrzysztofX <krzysztofx.zdziarski@intel.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: h

qat: Move qat_c2xxx firmware files and build glue into separate dirs

Reviewed by: Zdziarski, KrzysztofX <krzysztofx.zdziarski@intel.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36032

show more ...

qat: Import a new Intel (R) QAT driver

QAT in-tree driver ported from out-of-tree release available
from 01.org.

The driver exposes complete cryptography and data compression
API in the kernel and

qat: Import a new Intel (R) QAT driver

QAT in-tree driver ported from out-of-tree release available
from 01.org.

The driver exposes complete cryptography and data compression
API in the kernel and integrates with Open Crypto Framework.
Details of supported operations, devices and usage can be found
in man and on 01.org.

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>

Reviewed by: markj, jhb (OCF integration)
Reviewed by: debdrup, pauamma (docs)
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D34632

show more ...

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be kept
around to provide opencrypto offload support for those chipsets.

Reviewed by: pauamma, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35817

show more ...

mac: add new mac_ddb(4) policy

Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the sy

mac: add new mac_ddb(4) policy

Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the system state, including sensitive data such as
signing keys.

However, having some access to debugger functionality on production
systems may be useful in determining the cause of a panic or hang.
Therefore, it is desirable to have an optional policy which allows
limited use of ddb(4) while disabling the functionality which could
reveal system secrets.

This loadable MAC module allows for the use of some ddb(4) commands
while preventing the execution of others. The commands have been broadly
grouped into three categories:
- Those which are 'safe' and will not emit sensitive data (e.g. trace).
Generally, these commands are deterministic and don't accept
arguments.
- Those which are definitively unsafe (e.g. examine <addr>, search
<addr> <value>)
- Commands which may be safe to execute depending on the arguments
provided (e.g. show thread <addr>).

Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag.

Commands requiring extra validation can provide a function to do so.
For example, 'show thread <addr>' can be used as long as addr can be
checked against the system's list of process structures.

The policy also prevents debugger backends other than ddb(4) from
executing, for example gdb(4).

Reviewed by: markj, pauamma_gundo.com (manpages)
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35371

show more ...

cddl/*: add a WITH(OUT)_DTRACE option

Add an option to enable/disable DTrace without disabling ZFS. New
architectures such as CHERI may support ZFS before they support DTrace
and the old model of W

cddl/*: add a WITH(OUT)_DTRACE option

Add an option to enable/disable DTrace without disabling ZFS. New
architectures such as CHERI may support ZFS before they support DTrace
and the old model of WITHOUT_CDDL disabling both wasn't helpful.

For compatiblity, the CDDL option remains and WITHOUT_CDDL implies
WITHOUT_DTRACE. WITHOUT_DTRACE also implies WITHOUT_CTF.

As part of this change, largely convert cddl/*/Makefile to using the
more compact SUBDIR.${MK_<FOO>}+= form rather than using intermediate
variables.

Reviewed by: markj
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D35718

show more ...

ovpn: Introduce OpenVPN DCO support

OpenVPN Data Channel Offload (DCO) moves OpenVPN data plane processing
(i.e. tunneling and cryptography) into the kernel, rather than using tap
devices.
This avoi

ovpn: Introduce OpenVPN DCO support

OpenVPN Data Channel Offload (DCO) moves OpenVPN data plane processing
(i.e. tunneling and cryptography) into the kernel, rather than using tap
devices.
This avoids significant copying and context switching overhead between
kernel and user space and improves OpenVPN throughput.

In my test setup throughput improved from around 660Mbit/s to around
2Gbit/s.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34340

show more ...

modules: Only build MAC modules if options MAC is set

They are not loadable otherwise.

Reviewed by: emaste
MFC after: 1 week
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Different

modules: Only build MAC modules if options MAC is set

They are not loadable otherwise.

Reviewed by: emaste
MFC after: 1 week
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35369

show more ...

irdma: fix LINT-NOIP/NOINET/NOINET6 builds

This module depends on the presence of both INET and INET6 options in
order to compile.

Reviewed by: erj
Fixes: cdcd52d41e24 ("irdma: Add RDMA driver for

irdma: fix LINT-NOIP/NOINET/NOINET6 builds

This module depends on the presence of both INET and INET6 options in
order to compile.

Reviewed by: erj
Fixes: cdcd52d41e24 ("irdma: Add RDMA driver for Intel(R) Ethernet...")
Differential Revision: https://reviews.freebsd.org/D35343

show more ...

irdma: Add RDMA driver for Intel(R) Ethernet Controller E810

This is an initial commit for RDMA FreeBSD driver for Intel(R) Ethernet
Controller E810, called irdma. Supporting both RoCEv2 and iWARP

irdma: Add RDMA driver for Intel(R) Ethernet Controller E810

This is an initial commit for RDMA FreeBSD driver for Intel(R) Ethernet
Controller E810, called irdma. Supporting both RoCEv2 and iWARP
protocols in per-PF manner, RoCEv2 being the default.

Testing has been done using krping tool, perftest, ucmatose, rping,
ud_pingpong, rc_pingpong and others.

Signed-off-by: Eric Joyner <erj@FreeBSD.org>

Reviewed by: #manpages (pauamma_gundo.com) [documentation]
MFC after: 1 week
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D34690

show more ...

mac_pimd: Support for privilege drop in pimd

Create new kernel module for privilege check in case
the user wants to run pimd daemon.

Sponsored by: Stormshield
Obtained from: Semihalf

cgem: Support building as a loadable kernel module

For development, building a driver as kernel module is both convenient
and a time saver (no need for reboot on some change, testing it requires
jus

cgem: Support building as a loadable kernel module

For development, building a driver as kernel module is both convenient
and a time saver (no need for reboot on some change, testing it requires
just kldunload and kldload, a matter of seconds). For some special
cases, it may be even desirable to postpone initializing the network
interface after some action is done (loading a FPGA bitstream may be
required for Zynq/ZynqMP based hardware as an example).

Building is limited to ARM, ARM64 and RISC-V architectures (for Zynq,
ZynqMP, PolarFire Soc based boards, and HiFive based boards are known to
use CGEM at the moment).

Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34687

show more ...

rtw88: add man pages and hook up to build

Add man pages for rtw88 and rtw88fw. Install a copy of the firmware
license file and hook up the driver and firmware modules to the build.

MFC after: 2 we

rtw88: add man pages and hook up to build

Add man pages for rtw88 and rtw88fw. Install a copy of the firmware
license file and hook up the driver and firmware modules to the build.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Relnotes: yes

show more ...

Remove a stale comment.

The intr_disable as a macro was only a problem on arm and mips and
is no longer relevant after the mips removal.