bnxt: Do not compile on 32-bit platforms

The new bnxt_re driver doesn't compile on any of them (it uses writeq()
from the LinuxKPI, which isn't implemented there), and had already been
disconnected from the build on i386.

Reported by: Jenkins
Fixes: acd884dec99a ("RDMA/bnxt_re: Add bnxt_re RoCE driver")

ipfw: don't build the module if INET not in kernel

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1255

mac_do: add a new MAC/do policy and mdo(1) utility

This policy enables a user to become another user without having to be
root (hence no setuid binary). it is configured via rules using sysctl
security.mac.do.rules

For example:
security.mac.do.rules=uid=1001:80,gid=0:any

The above rule means the user identifier by the uid 1001 is able to
become user 80
Any user of the group 0 are allowed to become any user on the system.

The mdo(1) utility expects the MAC/do policy to be installed and its
rules defined.

Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D45145

sys/modules/dpdk_lpm4: do not build without INET

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1236

tpm: Refactor TIS and add a SPI attachment

Summary:
Though mostly used in x86 devices, TPM can be used on others, with a
direct SPI attachment. Refactor the TPM 2.0 driver set to use an
attachment interface, and implement a SPI bus interface.

Test Plan:
Tested on a Raspberry Pi 4, with a GeeekPi TPM2.0 module (SLB9670
TPM) using security/tpm2-tools tpm2_getcaps for very light testing against the
spibus attachment.

Reviewed by: kd
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D45069

nvmf: Add infrastructure kernel module for NVMe over Fabrics

nvmf_transport.ko provides routines for managing NVMeoF queue pairs
and capsules. It provides a glue layer between transports (such as
TCP or RDMA) and an NVMeoF host (initiator) and controller (target).

Unlike the synchronous API exposed to the host and controller by
libnvmf, the kernel's transport layer uses an asynchronous API built
on callbacks. Upper layers provide callbacks on queue pairs that are
invoked for transport errors (error_cb) or anytime a capsule is
received (receive_cb).

Data transfers for a command are usually associated with a callback
that is invoked once a transfer has finished either due to an error
or successful completion.

For an upper layer that is a host, command capsules are allocated and
populated with an NVMe SQE by calling nvmf_allocate_command. A data
buffer (described by a struct memdesc) can be associated with a
command capsule before it is transmitted via nvmf_capsule_append_data.
This function accepts a direction (send vs receive) as well as the
data transfer callback. The host then transmits the command via
nvmf_transmit_capsule. The host must ensure that the data buffer
described by the 'struct memdesc' remains valid until the data
transfer callback is called. The queue pair's receive_cb callback
should match received response capsules up with previously transmitted
commands.

For the controller, incoming commands are received via the queue
pair's receive_cb callback. nvmf_receive_controller_data is used to
retrieve any data from a command (e.g. the data for a WRITE command).
It can be called multiple times to split the data transfer into
smaller sizes. This function accepts an I/O completion callback that
is invoked once the data transfer has completed.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. In this case a callback function is not used
but the status is returned synchronously. Finally, the controller can
allocate a response capsule via nvmf_allocate_response populated with
a supplied CQE and send the response via nvmf_transmit_capsule.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44711

linuxkpi: Add linuxkpi_video module

This contain the hdmi code and the aperture code like in linux.

Differential Revision: https://reviews.freebsd.org/D44925
Reviewed by: bz
Obtained from: drm-kmod
Sponsored by: Beckhoff Automation GmbH & Co. KG

accf_tls: accept filter that waits for TLS handshake header

genet: add module (if_genet.ko)

The driver already had the appropriate module macros, it just wasn't
hooked into the build system.

Since this device is specific to the Raspberry Pi 4, only build it for
AArch64.

Reviewed by: imp, emaste (earlier version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1139

sys: Enable NVMe drivers on all architectures

The NVMe drivers are portable and are already included statically in
GENERIC on other architectures such as aarch64 and riscv64.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44690

vf_i2c: split up and add ACPI attachments in addition to FDT

Move the code from the arm specific to the iicbus controller directory.
Split up between general logic and bus attachment code.
Add support for ACPI attachment in addition to FDT.

MFC after: 7 days
Tested by: bz (LS1088a FDT), Pierre-Luc Drouin (Honeycomb, ACPI)
Based on: D24917 by Val Packett (initial early version)
Differential Revision: https://reviews.freebsd.org/D44020

Import the kernel parts of bhyve/arm64

To support virtual machines on arm64 add the vmm code. This is based on
earlier work by Mihai Carabas and Alexandru Elisei at University
Politehnica of Bucharest, with further work by myself and Mark Johnston.

All AArch64 CPUs should work, however only the GICv3 interrupt
controller is supported. There is initial support to allow the GICv2
to be supported in the future. Only pure Armv8.0 virtualisation is
supported, the Virtualization Host Extensions are not currently used.

With a separate userspace patch and U-Boot port FreeBSD guests are able
to boot to multiuser mode, and the hypervisor can be tested with the
kvm unit tests. Linux partially boots, but hangs before entering
userspace. Other operating systems are untested.

Sponsored by: Arm Ltd
Sponsored by: Innovate UK
Sponsored by: The FreeBSD Foundation
Sponsored by: University Politehnica of Bucharest
Differential Revision: https://reviews.freebsd.org/D37428

pflow: import from OpenBSD

pflow is a pseudo device to export flow accounting data over UDP.
It's compatible with netflow version 5 and IPFIX (10).

The data is extracted from the pf state table. States are exported once
they are removed.

Reviewed by: melifaro
Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43106

Revert "Don't try and run kldxref for arm kernels"

Now that kldxref supports arm this should not be needed.

This reverts commit 0840bdbf2a07b68e29267bc49057ca6df2351360.

Don't try and run kldxref for arm kernels

Surprisingly, kldxref does not currently support arm, and unhelpfully
this means it silently does nothing rather than give an error, so the
linker.hints entry added to the METALOG for -DNO_ROOT builds (and
pkgbase ones) refers to a file that doesn't exist. Ideally it would be
supported (and ideally the METALOG handling would be less fragile, but
without integrating it into kldxref the only real option would be to
just run find(1) to get the list of linker.hints files, which feels a
little backwards), but for now just paper over this by skipping the
build step on arm.

Reported by: bapt
Fixes: ff7c12c1f17e ("Make kldxref a bootstrap tool and use unconditionally")

Make kldxref a bootstrap tool and use unconditionally

Now that kldxref is a generic cross tool and can be built on non-FreeBSD
we can bootstrap it during the build and thus remove the condition for
whether it exists. We also need to make sure to add it to the METALOG
for -DNO_ROOT builds.

Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D43051

ossl: Add support for armv7

OpenSSL provides implementations of several AES modes which use
bitslicing and can be accelerated on CPUs which support the NEON
extension. This patch adds arm platform support to ossl(4) and provides
an AES-CBC implementation, though bsaes_cbc_encrypt() only implements
decryption. The real goal is to provide an accelerated AES-GCM
implementation; this will be added in a subsequent patch.

Initially derived from https://reviews.freebsd.org/D37420.

Reviewed by: jhb
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D41304

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.

Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.

On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.

Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411

rtw88: re-connect to the build

This adds the (updated) rtw88 driver back to the build.
Functionality has not been tested (much) so might not currently
work but people offered to test.

Firmware is provided by the wifi-firmware-rtw88-kmod port/package.

This reverts commit 712468443df1130db8f893a5e2ce5c6a8dbf5cde.

iwlwifi: re-attach to build after updates

While the build-breaking changes were only in the window of
the two commits, 3e1f5cc9a81a..9af1bba44e1c, further updates
restored some functionality as well. Now that we are done,
add iwlwifi back to the build.

This reverts commit b75d1ce6c10652fc4bfbf509deeae0e05c3d1356.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

iwlwifi: temporary disable build for updates

Disconnect iwlwifi from the build for a few commits which, due to
incompatible LinuxKPI 802.11 changes would break the build for a
revision. It will be re-enabled "instantly".

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

rtw88: temporary disconnect from build

As announced on freebsd-wireless [1] disconnect rtw88 from the build.
Add a note to the man page about the current state but leave the man
page in place for now as this is supposed to be temporary.

[1] https://lists.freebsd.org/archives/freebsd-wireless/2023-September/001377.html

MFC after: 20 days
X-MFC: will see about 14/13

rtw88: detach firmware from build

Firmware is kept in ports now and fwget will find the right one to
install.

MFC after: 20 days
X-MFC: will see about 14/13

sff: Add SFP driver (fdt-based draft)

This basic version of the driver obtains properties of the "sff,sfp"
compatible devices and implements a simple interface to provide an I2C
bus device for the rest of the drivers (e.g. to implement SIOCGI2C).

Both of the interface and driver are subjects for a further
generalization to be used in case of non-FDT and non-arm64 platforms.

Reviewed by: bz, manu
Approved by: bz (mentor)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D41440

sys: Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

ath(4): Remove MIPS AHB frontend and join PCI one w/ main support again

Following the removal of general MIPS support, there's no longer a need
to have the AHB bus-frontend in place, which according to Linux sources
also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support
is only made conditional on the main one again, i. e. device ath_pci is
removed, and built into the main module, i. e. if_ath_pci.ko obsoleted,
respectively.
Effectively, this reverts the following commits and associated changes:
dba9c8597747c6c9bf3d2ec68f7eb90552878dc7
e849bb3ecbb1963344a22ae77fc96f89fbebf40c

Approved by: adrian
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D41354

modules: Use MACHINE_CPUARCH more

Replace two cases of MACHINE_ARCH with MACHINE_CPUARCH and also use
`aarch64` instead of the improper `arm64` for that test.

Noticed by: Mark Millard
Sponsored by: Netflix

mac_ipacl: new MAC policy module to limit jail/vnet IP configuration

The mac_ipacl policy module enables fine-grained control over IP address
configuration within VNET jails from the base system.
It allows the root user to define rules governing IP addresses for
jails and their interfaces using the sysctl interface.

Requested by: multiple
Sponsored by: Google, Inc. (GSoC 2019)
MFC after: 2 months
Reviewed by: bz, dch (both earlier versions)
Differential Revision: https://reviews.freebsd.org/D20967

superio+ncthwm: Add hardware monitoring support

Add support for the following chips:
- Nuvoton NCT6779D
- Nuvoton NCT6796D-E

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/719

mpi3mr: 3rd Generation Tri-Mode NVMe/SAS/SATA MegaRaid / eHBA

This is Broadcom's mpi3mr driver for FreeBSD version 8.6.0.2.0.
The mpi3mr driver supports Broadcom SAS4116-based cards in the 9600
series: 9670W-16i, 9670-24i, 9660-16i, 9620-16i, 9600-24i, 9600-16i,
9600W-16e, 9600-16e, 9600-8i8e.

Initially only available as a module and on amd64/arm64, since that's
how it has been tested to date. Future commits will add it to the kernel
build and may expand the architectures it is supported on.

Co-authored-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Feedback-by: ken (prior versions)
Reviewed-by: imp
RelNotes: yes
Differential-Revision: https://reviews.freebsd.org/D36771
Differential-Revision: https://reviews.freebsd.org/D36772

qatfw: Don't build if WITH_SOURCELESS_UCODE is defined

qat: Stop building on i386

The driver isn't tested on i386, so don't spend effort compiling it.

gve: Fix build on i386 and enable LINT builds.

Reviewed-by: imp
Differential Revision: https://reviews.freebsd.org/D40419

Add gve, the driver for Google Virtual NIC (gVNIC)

gVNIC is a virtual network interface designed specifically for
Google Compute Engine (GCE). It is required to support per-VM Tier_1
networking performance, and for using certain VM shapes on GCE.

The NIC supports TSO, Rx and Tx checksum offloads, and RSS.
It does not currently do hardware LRO, and thus the software-LRO
in the host is used instead. It also supports jumbo frames.

For each queue, the driver negotiates a set of pages with the NIC to
serve as a fixed bounce buffer, this precludes the use of iflib.

Reviewed-by: markj
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D39873

nlsysevent: add a genetlink(4) module to report kernel events

Hooked to devctl_notify, this allows consumers to received events
by subscribing to a system over a generic netlink protocol

Reviewed by: imp, melifaro
Differential Revision: https://reviews.freebsd.org/D37574

twe: Remove driver

Sponsored by: Netflix

tests: add ktest modules to build

MFC after: 2 weeks

sys/modules/Makefile: conditionally add MAC/veriexec modules

Only build MAC/veriexec modules when MK_VERIEXEC is yes or we
are building all modules.

Add VERIEXEC knob to kernel __DEFAULT_NO_OPTIONS

Reviewed by: sjg
Obtained from: Juniper Networks, Inc.

sys/modules/Makefile: add MAC/veriexec modules into the build

Build the MAC/veriexec module and the SHA2, SHA256, SHA384, and
SHA512 fingerprint modules.

Obtained from: Juniper Networks, Inc.

linuxkpi: Add hdmi helpers

This is a direct port of the Linux code as the licence allows it, so
style(9) isn't respected to allow applying directly the upstream commits.
Do not add it to linuxkpi directly but add a new linuxkpi_hdmi module
that drm modules will require later, no need to bloat linuxkpi more.

Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39122

powerpc: enable ZFS on 32 bit powerpc/powerpcspe

Enable ZFS on powerpc 32 bit since it appears to build and work
correctly.

MFC after: 3 weeks
Relnotes: yes

sys/modules/Makefile: Add a section for arm64 + x86 + powerpc64.

This reduces some duplication between the existing arm64 + x86 section
and the powerpc64 section. To make the diff simpler, enable mlx4 on
powerpc64 since it compiles.

Reviewed by: pkubaj, imp, emaste
Differential Revision: https://reviews.freebsd.org/D38973

Enable OFED on all platforms except for 32-bit arm.

32-bit arm triggers multiple -Wunaligned-access errors due to
structure packing.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38972

superio,ftgpio: Add support for Fintek F81865 GPIO

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/674
Differential Revision: https://reviews.freebsd.org/D37893

powerpc64*: port mlx5, OFED, KTLS and krping

Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.

krping requires a small change since it uses assembly for amd64 / i386.

NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.

Reviewers: #powerpc, hselasky

Subscribers: bdrewery, imp, emaste, jhibbits

Differential Revision: https://reviews.freebsd.org/D38786

Revert "powerpc64*: port mlx5, OFED, KTLS and krping"

Wrong push, another commit was supposed to be pushed.

This reverts commit 83d6d8877ef7dad4f4e8f409a01c9f28139cd026.

powerpc64*: port mlx5, OFED, KTLS and krping

Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.

krping requires a small change since it uses assembly for amd64 / i386.

NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.

Reviewers: #powerpc, hselasky

Subscribers: bdrewery, imp, emaste, jhibbits

Differential Revision: https://reviews.freebsd.org/D38786

enic: Cisco VIC driver

This driver is based of the enic (Cisco VIC) DPDK driver. It provides
basic ethernet functionality. Has been run with various VIC cards to
do UEFI PXE boot with NFS root.

Add tarfs, a filesystem backed by tarballs.

Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: pauamma, imp
Differential Revision: https://reviews.freebsd.org/D37753

wdatwd: Add support for ACPI WDAT based watchdog timer.

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

retire cp(4) driver

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

retire ce(4) driver

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

bnxt: Only filter out i386

Only i386 is missing bus_read_8. The other 32-bit platforms can be fixed
with a cast to a printf.

Suggested by: kevans
Sponsored by: Netflix

bnxt: Only build on 64-bit platforms

The driver uses bus_space_read_8 and friends, which do not exist on
32-bit i386 and break the build.

Sponsored by: Netflix

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

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

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

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

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, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37178

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

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

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

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.

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

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

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

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

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

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

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

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

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

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
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

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

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.

powerpc: enable ice in GENERIC64LE

Approved by: erj
Differential Revision: https://reviews.freebsd.org/D33974

mips: Remove system module support

Remove all mips .if conditionals. Since _sym was now set
unconditionally, just add it to the right place w/o a variable.

Sponsored by: Netflix

hwpmc: deorbit mips support

Sponsored by: Netflix

iwlwifi: attach to the build

Add iwlwifi and iwlwififw to the module builds.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

LinuxKPI: add 802.11 compat code

Add 802.11 compat code for mac80211 and to a minimal degree cfg80211.
This allows us to compile and use basic functionality of wireless
drivers such as iwlwifi.

This is a constant work in progress but having it in the tree will
allow others to test and more easy to track changes and avoid having
snapshots no longer applying to branches.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

amd64: Only build aout.ko when COMPAT_FREEBSD32 is enabled

a.out.ko is useless without COMPAT_FREEBSD32, and since vdso support was
added, it requires a header built during depend phase, from the COMPAT
option.

Reported by: glebius
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33311

MAC/priority module for realtime privilege group

This is a MAC policy module that grants scheduling privileges based on
group membership. Users or processes in the group realtime (gid 47) are
allowed to run threads and processes with realtime scheduling priority.
For timing-sensitive, low-latency software like audio/jack, running with
realtime priority helps to avoid stutter and gaps.

PR: 239125
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D33191

flex_spi: Support for FlexSPI Flash controller.

NXP FlexSPI is a complex SPI controller which provides
full offload for accessing NOR Flash.
Create a Flash driver which attaches to existing FreeBSD
infrastructure and exports generic READ and WRITE disk commands.
The Flash has to be identified first to configure controller
internals. For now, only one NOR Flash chip is supported.
Future commits shall either increase number of known chips
or implement SFDP mechanism which can be used by other Flash
drivers.

Sponsored by: Alstom
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D33117

twa: Remove

Belatedly remove twa(4). It was supposed to go before 13.0, but was
overlooked.

Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33114

esp: Remove

Belatedly remove esp(4). It was tagged as gone in 13, but was overlooked
until now.

Sponsored by: Netflix
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33115

amr: remove

Belatedly remove amr(4). It was slated to depart before 13.0 but was
overlooked until now.

Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33113

iir: Remove

Belatedly remove iir(4). It was slated to go before 13, but was
overlooked.

Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33112

mly: Remove.

We'd said this was going away in 13, but was overlooked. Belatedly
remove.

Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33111

Remove enetc_mdio driver

It was previously used by felix(4) for PHY communication.
Since that is not the case anymore this driver is now left unused.

Obtained from: Semihalf
Sponsored by: Alstom Group

Retire obsolete iscsi_initiator(4)

The new iSCSI initiator iscsi(4) was introduced with FreeBSD 10.0, and
the old intiator was marked obsolete shortly thereafter (in commit
d32789d95cfbf, MFC'd to stable/10 in ba54910169c4). Remove it now.

Reviewed by: jhb, mav
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32673

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware/wan.html>.

Since Roman Kurakin <rik@FreeBSD.org> has quit them, they no
longer support FreeBSD officially. Later they have dropped
support for Linux drivers to. As of mid-2020 they don't even
have a developer to maintain their Windows driver. However,
their support verbally told me that they could provide aid to
a FreeBSD developer with documentaion in case if there appears
a new customer for their devices.

These drivers have a feature to not use sppp(4) and create an
interface, but instead expose the device as netgraph(4) node.
Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
top of the node and get your synchronous PPP. Alternatively
you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
Actually, last time I used cp(4) back in 2004, using netgraph(4)
instead of sppp(4) was already the right way to do.

Thus, remove the sppp(4) related part of the drivers and enable
by default the negraph(4) part. Further maintenance of these
drivers in the tree shouldn't be a big deal.

While doing that, remove some cruft and enable cp(4) compilation
on amd64. The ce(4) for some unknown reason marks its internal
DDK functions with __attribute__ fastcall, which most likely is
safe to remove, but without hardware I'm not going to do that, so
ce(4) remains i386-only.

Reviewed by: emaste, imp, donner
Differential Revision: https://reviews.freebsd.org/D32590
See also: https://reviews.freebsd.org/D23928

mgb: Connect if_mgb module to the build

It supports the following Microchip devices:

LAN7430 PCIe Gigabit Ethernet controller with PHY
LAN7431 PCIe Gigabit Ethernet controller with RGMII interface

The driver has a number of caveats and limitations, but is functional.

Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Drop cloudabi

According to https://github.com/NuxiNL/cloudlibc:
CloudABI is no longer being maintained. It was an awesome experiment,
but it never got enough traction to be sustainable.

There is no reason to keep it in FreeBSD.

Approved by: ed (private mail)
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D31923

if_mvneta: Build the driver as a kernel module

Fix device detach and attach routine. Add required Makefile
to build as a module. Remove entry from GENERIC, since now
it can be loaded automatically.

Tested on EspressoBin.

Obtained from: Semihalf
Reviewed by: manu
Differential revision: https://reviews.freebsd.org/D31581

Revert "if_mvneta: Build the driver as a kernel module"

This reverts commit bcf5c7a8b1dcdcd5f27c1aa694f66208dc07a0dd.

if_mvneta: Build the driver as a kernel module

Fix device detach and attach routine. Add required Makefile
to build as a module. Remove entry from GENERIC, since now
it can be loaded automatically.

Tested on EspressoBin.

Obtained from: Semihalf
Reviewed by: manu
Differential revision: https://reviews.freebsd.org/D31581

Revert "if_mvneta: Build the driver as a kernel module"

This reverts commit 41b0190cc404e21cb8b430602eabfedc20107471.

if_mvneta: Build the driver as a kernel module

Fix device detach and attach routine. Add required Makefile
to build as a module. Remove entry from GENERIC, since now
it can be loaded automatically.

Tested on EspressoBin.

Obtained from: Semihalf
Reviewed by: manu
Differential revision: https://reviews.freebsd.org/D31581

e6000sw: Build the driver as a kernel module

Fix detach routine.
Driver was tested on EspressoBin.
Remove it from GENERIC, since now it can be loaded automatically.

Obtained from: Semihalf
Reviewed by: manu
Differential revision: https://reviews.freebsd.org/D31580

vmd(4): Major driver refactoring

- Re-implement pcib interface to use standard pci bus driver on top of
vmd(4) instead of custom one.
- Re-implement memory/bus resource allocation to properly handle even
complicated configurations.
- Re-implement interrupt handling to evenly distribute children's MSI/
MSI-X interrupts between available vmd(4) MSI-X vectors and setup them
to be handled by standard OS mechanisms with minimal overhead, except
sharing when unavoidable.

Successfully tested on Dell XPS 13 laptop with Core i7-1185G7 CPU (VMD
device ID 0x9a0b) and single NVMe SSD, dual-booting with Windows 10.

Successfully tested on Supermicro X11DPI-NT motherboard with Xeon(R)
Gold 6242R CPUs (VMD device ID 0x201d), simultaneously handling NVMe
SSD on one PCIe port and PLX bridge with 3 NVMe and 1 AHCI SSDs on
another. Handles SSD hot-plug (except Optane 905p for some reason,
which are not detected until manual bus rescan) and enabled IOMMU
(directly connected SSDs work, but ones connected to the PLX fail
without errors from IOMMU).

MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential revision: https://reviews.freebsd.org/D31762

Add support for Lewisburg GPIO through P2SB

Obtained from: Semihalf
Sponsored by: Stormshield
Differential revision: https://reviews.freebsd.org/D31269

Microsoft Azure Network Adapter(MANA) VF support

MANA is the new network adapter from Microsoft which will be available
in Azure public cloud. It provides SRIOV NIC as virtual function to
guest OS running on Hyper-V.

The code can be divided into two major parts. Gdma_main.c is the one to
bring up the hardware board and drives all underlying hardware queue
infrastructure. Mana_en.c contains all main ethernet driver code.
It has only tested and supported on amd64 architecture.

PR: 256336
Reviewed by: decui@microsoft.com
Tested by: whu
MFC after: 2 week
Relnotes: yes
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D31150

enetc_mdio: Support building the driver as a loadable module.

After recent arm64 GENERIC config cleanup the ENETC MDIO
in NXP LS1028A SoC should support being loaded as a module.

Obtained from: Semihalf
Sponsored by: Alstom Group

enetc: Support building the driver as a loadable module.

Function level reset has to be done in attach in order to put the
hardware in a known state before configuring it.
The order of DRIVER_MODULEs was changed to ensure that the miibus driver
is loaded when mii_attach is called.

Obtained from: Semihalf
Sponsored by: Alstom Group

Introduce driver for Freescale Felix switch

It is found on boards equipped with LS1028A SoC.
802.1q VLAN grouping is supported.
An external MDIO device is used for communicating with PHYs.
The driver is built as a module by default, it is not included
in GENERIC kernel config.

Submitted by: Lukasz Hajec <lha@semihalf.com>
Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D30923

pccard: remove pccard module

There's no more pccard client drivers, so remove pccard driver.

Sponsored by: Netflix

igc(4): Introduce new driver for the Intel I225 Ethernet controller.

This controller supports 2.5G/1G/100MB/10MB speeds, and allows
tx/rx checksum offload, TSO, LRO, and multi-queue operation.

The driver was derived from code contributed by Intel, and modified
by Netgate to fit into the iflib framework.

Thanks to Mike Karels for testing and feedback on the driver.

Reviewed by: bcr (manpages), kbowling, scottl, erj
MFC after: 1 month
Relnotes: yes
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30668

an: Remove driver

Last an(4) devices have been End Of Life and End Of Sale in 2007.
Time to remove this driver.

Differential Revision: https://reviews.freebsd.org/D30679
Reviewed by: imp (earlier version), emaste (earlier version)
Sponsored by: Diablotin Systems

Assume OCF is the only KTLS software backend.

This removes support for loadable software backends. The KTLS OCF
support is now always included in kernels with KERN_TLS and the
ktls_ocf.ko module has been removed. The software encryption routines
now take an mbuf directly and use the TLS mbuf as the crypto buffer
when possible.

Bump __FreeBSD_version for software backends in ports.

Reviewed by: gallatin, markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30138

modules: Only build sdhci_fdt for arm and arm64

Other FDT platform (like powerpc64* or riscv64) don't have gpio built
by default so just compile the module for those two arches.

Fixes: 9e08f82058cb ("modules: Add sdhci_fdt module")

modules: Add sdhci_fdt module

This is a module for sdhci on fdt system

Introduce DXR as an IPv4 longest prefix matching / FIB module

DXR maintains compressed lookup structures with a trivial search
procedure. A two-stage trie is indexed by the more significant bits of
the search key (IPv4 address), while the remaining bits are used for
finding the next hop in a sorted array. The tradeoff between memory
footprint and search speed depends on the split between the trie and
the remaining binary search. The default of 20 bits of the key being
used for trie indexing yields good performance (see below) with
footprints of around 2.5 Bytes per prefix with current BGP snapshots.

Rebuilding lookup structures takes some time, which is compensated for by
batching several RIB change requests into a single FIB update, i.e. FIB
synchronization with the RIB may be delayed for a fraction of a second.
RIB to FIB synchronization, next-hop table housekeeping, and lockless
lookup capability is provided by the FIB_ALGO infrastructure.

DXR works well on modern CPUs with several MBytes of caches, especially
in VMs, where is outperforms other currently available IPv4 FIB
algorithms by a large margin.

Synthetic single-thread LPM throughput test method:

kldload test_lookup; kldload dpdk_lpm4; kldload fib_dxr
sysctl net.route.test.run_lps_rnd=N
sysctl net.route.test.run_lps_seq=N

where N is the number of randomly generated keys (IPv4 addresses) which
should be chosen so that each test iteration runs for several seconds.

Each reported score represents the best of three runs, in million
lookups per second (MLPS), for two bechmarks (RND & SEQ) with two FIBs:

host: single interface address, local subnet route + default route
BGP: snapshot from linx.routeviews.org, 887957 prefixes, 496 next hops

Bhyve VM on an Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 40.6 20.2 N/A N/A
radix4 7.8 3.8 1.2 0.6
radix4_lockless 18.0 9.0 1.6 0.8
dpdk_lpm4 14.4 5.0 14.6 5.0
dxr 70.3 34.7 43.0 19.5

Intel(R) Core(TM) i5-5300U CPU @ 2.30 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 47.0 23.1 N/A N/A
radix4 8.5 4.2 1.9 1.0
radix4_lockless 19.2 9.5 2.5 1.2
dpdk_lpm4 31.2 9.4 31.6 9.3
dxr 84.9 41.4 51.7 23.6

Intel(R) Core(TM) i7-4771 CPU @ 3.50 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 59.5 29.4 N/A N/A
radix4 10.8 5.5 2.5 1.3
radix4_lockless 24.7 12.0 3.1 1.6
dpdk_lpm4 29.1 9.0 30.2 9.1
dxr 101.3 49.9 69.8 32.5

AMD Ryzen 7 3700X 8-Core Processor @ 3.60 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 70.8 35.4 N/A N/A
radix4 14.4 7.2 2.8 1.4
radix4_lockless 30.2 15.1 3.7 1.8
dpdk_lpm4 29.9 9.0 30.0 8.9
dxr 163.3 81.5 99.5 44.4

AMD Ryzen 5 5600X 6-Core Processor @ 3.70 GHz:
inet.algo host, RND host, SEQ BGP, RND BGP, SEQ
bsearch4 93.6 46.7 N/A N/A
radix4 18.9 9.3 4.3 2.1
radix4_lockless 37.2 18.6 5.3 2.7
dpdk_lpm4 51.8 15.1 51.6 14.9
dxr 218.2 103.3 114.0 49.0

Reviewed by: melifaro
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29821

modules: remove stale if_wg reference

This variable isn't being used anywhere, remove it.

base: remove if_wg(4) and associated utilities, manpage

After length decisions, we've decided that the if_wg(4) driver and
related work is not yet ready to live in the tree. This driver has
larger security implications than many, and thus will be held to
more scrutiny than other drivers.

Please also see the related message sent to the freebsd-hackers@
and freebsd-arch@ lists by Kyle Evans <kevans@FreeBSD.org> on
2021/03/16, with the subject line "Removing WireGuard Support From Base"
for additional context.

if_wg: fix the !INET6 support

INET is still required, so formally don't build it in !INET
configurations.

ndis(4): remove as previous announced

nids(4) was a clever idea in the early 2000's when the market was
flooded with 10/100 NICs with Windows-only drivers, but that hasn't been
the case for ages and the driver has had no meaningful maintenance in
ages. It only supports Windows-XP era drivers.

Also remove:
- ndis support from wpa_supplicant
- ndiscvt(8)

Reviewed By: emaste, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D27609

Build VirtIO modules on all architectures

Currently only amd64, i386 and powerpc build VirtIO modules, yet all other
architectures have at least one kernel configuration that includes the
transport drivers, and so they lack drivers for all the devices they don't
statically compile into the kernel. Instead, enable the build everywhere so all
architectures have the full set of device drivers available.

Reviewed by: bryanv (earlier version), imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D28058

Add driver for Synopsys Designware Watchdog timer.

This driver supports some arm and arm64 boards equipped with
"snps,dw-wdt"-compatible watchdog device.
Tested on RK3399-based board (RockPro64).
Once started watchdog device cannot be stopped.
Interrupt handler has mode to kick watchdog even when software does not do it
properly.
This can be controlled via sysctl: dev.dwwdt.prevent_restart.
Also - driver handles system shutdown and prevents from restart when system
is asked to reboot.

Submitted by: kjopek@gmail.com
Differential Revision: https://reviews.freebsd.org/D26761

Bring DPDK route lookups to FreeBSD.

This change introduces loadable fib lookup modules based on
DPDK rte_lpm lib targeted for high-speed lookups in large-scale tables.
It is based on the lookup framework described in D27401.

IPv4 module is called dpdk_lpm4. It wraps around rte_lpm [1] library.
This library implements variation of DIR24-8 [2] lookup algorithm.
Module provide lockless route lookups and in-place incremental updates,
allowing for good RIB performance.

IPv6 module is called dpdk_lpm6. It wraps around rte_lpm6 [3] library.
Implementation can be seen as multi-bit trie where the stride or number of bits
inspected on each level varies from level to level.
It can vary from 1 to 14 memory accesses, with 5 being the average value
for the lengths that are most commonly used in IPv6.
Module provide lockless route lookups for global unicast addresses
and in-place incremental updates, allowing for good RIB performance.

Implementation details:
* wrapper code lives in `sys/contrib/dpdk_rte_lpm/dpdk_lpm[6].c`.
* rte_lpm[6] implementation contains both RIB and FIB code.
. RIB ("rule_") code, backed by array of hash tables part has been commented out,
as base radix already provides all the necessary primitives.
* link-local lookups are currently implemented as base radix lookup.
This part should be converted to something like read-only radix trie.

Usage detail:
Compile kernel with option FIB_ALGO and load dpdk_lpm4/dpdk_lpm6
module at any time. They will be picked up automatically when
amount of routes raises to several thousand.

[1]: https://doc.dpdk.org/guides/prog_guide/lpm_lib.html
[2]: http://yuba.stanford.edu/~nickm/papers/Infocom98_lookup.pdf
[3]: https://doc.dpdk.org/guides/prog_guide/lpm6_lib.html

Differential Revision: https://reviews.freebsd.org/D27412

pccard: Remove wi(4) driver

Remove wi(4). pccard is going away, and wi only supports PC Card
devices, though it has a minor amount of glue to also support
PCI cards. However, removing the one without removing the other
is hard, so the whole driver is being removed.

Relnotes: Yes

pccard: Remove cmx(4) driver

The only attachment of cmx was pccard, so remove the driver in
anticipation of PC Card support removal.

Relnotes: Yes

Factor-out hardware-independent part of USB HID support to new module

It will be used by the upcoming HID-over-i2C implementation. Should be
no-op, except hid.ko module dependency is to be added to affected drivers.

Reviewed by: hselasky, manu
Differential revision: https://reviews.freebsd.org/D27867

arm64: enable build of the ipmi module

Only ACPI attachment is supported for now, some others depend on the
presence of smbios(4) support, which we lack on arm64.

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

Move cp(4) module enable to SOURCELESS_HOST

cp contains obfuscated code that runs on the host's processor

hme(4): Remove as previous announced

The hme (Happy Meal Ethernet) driver was the onboard NIC in most
supported sparc64 platforms. A few PCI NICs do exist, but we have seen
no evidence of use on non-sparc systems.

Reviewed by: imp, emaste, bcr
Sponsored by: DARPA

ossl: port to arm64

Enable in-kernel acceleration of SHA1 and SHA2 operations on arm64 by adding
support for the ossl(4) crypto driver. This uses OpenSSL's assembly routines
under the hood, which will detect and use SHA intrinsics if they are
supported by the CPU.

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27390

Import kernel WireGuard support

Data path largely shared with the OpenBSD implementation by
Matt Dunwoodie <ncon@nconroy.net>

Reviewed by: grehan@freebsd.org
MFC after: 1 month
Sponsored by: Rubicon LLC, (Netgate)
Differential Revision: https://reviews.freebsd.org/D26137

Add watchdog(9) driver for the Fintek F81803 SuperIO chip

Port rtsx(4) driver for Realtek SD card reader from OpenBSD.

This driver provides support for Realtek PCI SD card readers. It attaches
mmc(4) bus on card insertion and detaches it on card removal. It has been
tested with RTS5209, RTS5227, RTS5229, RTS522A, RTS525A and RTL8411B. It
should also work with RTS5249, RTL8402 and RTL8411.

PR: 204521
Submitted by: Henri Hennebert (hlh at restart dot be)
Reviewed by: imp, jkim
Differential Revision: https://reviews.freebsd.org/D26435

Add firmware modules for qat(4)

MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)

Add qat(4)

This provides an OpenCrypto driver for Intel QuickAssist devices. The
driver was initially ported from NetBSD and comes with a few
improvements:
- support for GMAC/AES-GCM, AES-CTR and AES-XTS, and support for
SHA/HMAC-authenticated encryption
- support for detaching the driver
- various bug fixes
- DH895X support

Discussed with: jhb
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
Differential Revision: https://reviews.freebsd.org/D26963

Factor out generic IP over infiniband, IPoIB, definitions and code
into net/if_infiniband.c and net/infiniband.h . No functional change
intended.

Differential Revision: https://reviews.freebsd.org/D26254
Reviewed by: melifaro@
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

Add a kernel crypto driver using assembly routines from OpenSSL.

Currently, this supports SHA1 and SHA2-{224,256,384,512} both as plain
hashes and in HMAC mode on both amd64 and i386. It uses the SHA
intrinsics when present similar to aesni(4), but uses SSE/AVX
instructions when they are not.

Note that some files from OpenSSL that normally wrap the assembly
routines have been adapted to export methods usable by 'struct
auth_xform' as is used by existing software crypto routines.

Reviewed by: gallatin, jkim, delphij, gnn
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26821

build vmware modules on arm64

pvscsi and vmxnet3 build and work. Exclude vmci for now as it contains
x86-specific assembly.

Reported by: Vincent Milum Jr
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation

Don't build the malo module with clang 10

Compiling it with LLVM 10 triggers https://bugs.llvm.org/show_bug.cgi?id=44351
While LLVM 11 is the default compiler, I regularly build with
CROSS_TOOLCHAIN=llvm10 or use system packages for clang on Linux/macOS and
those have not been updated to 11 yet.

10Gigabit Ethernet driver for AMD SoC

This patch has the driver for 10Gigabit Ethernet controller in AMD
SoC. This driver is written compatible to the Iflib framework. The
existing driver is for the old version of hardware. The submitted
driver here is for the recent versions of the hardware where the Ethernet
controller is PCI-E based.

Submitted by: Rajesh Kumar <rajesh1.kumar@amd.com>
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25793

Remove apm module

The apm code is about to be removed. Remove the module since it's
about to be useless.

Add backlight subsystem

This is a simple subsystem that allow drivers to register as a backlight.
Each backlight creates a device node under /dev/backlight/backlightX and
an alias based on the name provided.

Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26250

[PowerPC64LE] Set up powerpc.powerpc64le architecture

This is the initial set up for PowerPC64LE.

The current plan is for this arch to remain experimental for FreeBSD 13.

This started as a weekend learning project for me and kinda snowballed from
there.

(More to follow momentarily.)

Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399

[PowerPC64LE] Ensure nvram is built on powerpc64le.

Fix some cases where conditionals that were trying to exclude powerpcspe
were also excluding powerpc64le.

Sponsored by: Tag1 Consulting, Inc.

Driver for 4x10Gb Ethernet reference NIC FPGA design for NetFPGA SUME
development board.

Submitted by: Denis Salopek <denis.salopek AT fer.hr>
Reported by: zec, bz (src); rgrimes, bcr (manpages)
MFC after: 7 days
Sponsored by: Google Summer of Code 2020
Differential Revision: https://reviews.freebsd.org/D26074

Merge OpenZFS support in to HEAD.

The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.

I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.

Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.

Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.

Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.

Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872

Move Ti AM335x to dev/extres/clk framework.

Re-implement clocks for these SoC by using now standard extres/clk framework.
This is necessary for future expansion of these. The new implementation
is (due to the size of the patch) only the initial (minimum) version.
It will be updated/expanded with a subsequent set of particular patches.

This patch is also not tested on OMAP4 based boards (BeagleBone),
so all possible issues should be (and will be) fixed by ASAP once
identified.

Submited by: Oskar Holmlund (oskar.holmlund@ohdata.se)
Differential Revision: https://reviews.freebsd.org/D25118

Make efirt module dependent on MK_EFI

MK_EFI was added to kern.opts.mk in r331099, but is currently unused.
Take advantage of that fact and gate the build of efirt behind it.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24673

Add a driver for the SafeXcel EIP-97.

The EIP-97 is a packet processing module found on the ESPRESSObin. This
commit adds a crypto(9) driver for the crypto and hash engine in this
device. An initial skeleton driver that could attach and submit
requests was written by loos and others at Netgate, and the driver was
finished by me.

Support for separate AAD and output buffers will be added in a separate
commit, to simplify merging to stable/12 (where those features don't
exist).

Reviewed by: gnn, jhb
Feedback from: andrew, cem, manu
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC (Netgate)
Differential Revision: https://reviews.freebsd.org/D25417

Provide support for building SCTP as a loadable module.

With this change, a kernel compiled with "options SCTP_SUPPORT" and
without "options SCTP" supports dynamic loading of the SCTP stack.

Currently sctp.ko cannot be unloaded since some prerequisite teardown
logic is not yet implemented. Attempts to unload the module will return
EOPNOTSUPP.

Discussed with: tuexen
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21997

modules: don't build ipsec/tcpmd5 if the kernel is configured for IPSEC

IPSEC_SUPPORT can currently only cope with either IPSEC || IPSEC_SUPPORT,
not both. Refrain from building if IPSEC is set, as the resulting module
won't be able to load anyways if it's built into the kernel.

KERN_OPTS is safe here; for tied modules, it will reflect the kernel
configuration. For untied modules, it will defer to whatever is set in
^/sys/conf/config.mk, which doesn't set IPSEC for modules. The latter
situation has some risk to it for uncommon scenarios, but such is the life
of untied kernel modules.

Reported by: jenkins (a lot), O. Hartmann (once)
Generally discussed with: imp, jhb

Only build ipsec modules if the kernel includes IPSEC_SUPPORT.

Honoring the kernel-supplied opt_ipsec.h in r361632 causes builds of
ipsec modules to fail if the kernel doesn't include IPSEC_SUPPORT.
However, the module can never be loaded into such a kernel, so only
build the modules if the kernel includes IPSEC_SUPPORT.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D25059

ice(4): Introduce new driver for Intel E800 Ethernet controllers

The ice(4) driver is the driver for the Intel E8xx series Ethernet
controllers; currently with codenames Columbiaville and
Columbia Park.

These new controllers support 100G speeds, as well as introducing
more queues, better virtualization support, and more offload
capabilities. Future work will enable virtual functions (like
in ixl(4)) and the other functionality outlined above.

For full functionality, the kernel should be compiled with
"device ice_ddp" like in the amd64 NOTES file, and/or
ice_ddp_load="YES" should be added to /boot/loader.conf so that
the DDP package file included in this commit can be downloaded
to the adapter. Otherwise, the adapter will fall back to a single
queue mode with limited functionality.

A man page for this driver will be forthcoming.

MFC after: 1 month
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D21959

Remove tests for obsolete compilers in the build system

Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.

Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802

Remove ubsec(4).

This driver was previously marked for deprecation in r360710.

Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24766

Split XDR into separate kernel module. Make krpc depend on xdr.

Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D24408

Remove the old NFS lock device driver that uses Giant.

This NFS lock device driver was replaced by the kernel NLM around FreeBSD7 and
has not normally been used since then.
To use it, the kernel had to be built without "options NFSLOCKD" and
the nfslockd.ko had to be deleted as well.
Since it uses Giant and is no longer used, this patch removes it.

With this device driver removed, there is now a lot of unused code
in the userland rpc.lockd. That will be removed on a future commit.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D22933

Add Platform Controller Hub built-in thermal management device driver.

Differential Revision: https://reviews.freebsd.org/D24077

retire cx,ctau drivers

The devices supported by these drivers are obsolete ISA cards, and the
sync serial protocols they supported are essentially obsolete too.

Sponsored by: The FreeBSD Foundation

Enable ixl device on PowerPC64

The ixl driver now works on PowerPC64 and may be compiled in-kernel and
as a module.

Reviewed by: alfredo, erj
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23974

[aacraid] Port driver to big-endian

Port aacraid driver to big-endian (BE) hosts.

The immediate goal of this change is to make it possible to use the
aacraid driver on PowerPC64 machines that have Adaptec Series 8 SAS
controllers.

Adapters supported by this driver expect FIB contents in little-endian
(LE) byte order. All FIBs have a fixed header part as well as a data
part that depends on the command being issued to the controller.

In this way, on BE hosts, the FIB header and all FIB data structures
used in aacraid.c and aacraid_cam.c need to be converted to LE before
being sent to the adapter and converted to BE when coming from it.

The functions to convert each struct are on aacraid_endian.c.
For little-endian (LE) targets, they are macros that expand
to nothing.
In some cases, when only a few fields of a large structure are used,
the fields are converted inline, by the code using them.

PR: 237463
Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23887

Remove bktr(4)

Remove the brooktree driver as discussed on arch@. Bump FreeBSD version to
1300082, though I doubt anything will care.

Relnote: yes

Fix build of some modules for some kernel configs.

Namely, vmm.ko cannot be compiled without 'option SMP', the code uses
IPIs and LAPIC.
Recently systrace was forced over any configs, check for KDTRACE_HOOK
before compiling the dtrace/ modules.

Reviewed by: markj
Discussed with: mjg
Tested by: se (previous version)
Sponsored by: The FreeBSD Foundation (kib)
Differential revision: https://reviews.freebsd.org/D23699

Remove sparc64 kernel support

Remove all sparc64 specific files
Remove all sparc64 ifdefs
Removee indireeect sparc64 ifdefs

Move ce enable to SOURCELESS_HOST

ce contains obfuscated code that runs on the host's processor

Remove vpo.4

The Parallel Port SCSI adapter was interesting for 100MB ZIP drives, but is no
longer used or maintained. Remove it from the tree.

The Parallel Port microsequencer (microseq.9) is now mostly unused in the tree,
but remains. PPI still refrences it, but doesn't use its full functionality.

Relnotes: Yes
Reviewed by: rgrimes@, Ihor Antonov
Discussed on: arch@
Differential Revision: https://reviews.freebsd.org/D23389

[PowerPC64] Enable virtio drivers

This enables virtio modules on PowerPC* target.
On PowerPC64, drivers are also kernel builtin.

QEMU currently needs to be patched to in order to work on LE hosts due to known
issue affecting pre-1.0 (legacy) virtio drivers.

The patch was submitted to QEMU mail list by @afscoelho_gmail.com, available at
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg01496.html

Submitted by: Alfredo Dal'Ava Junior <alfredo.junior@eldorado.org.br>
Reviewed by: luporl
Differential Revision: https://reviews.freebsd.org/D22833

Remove the trm(4) driver

Differential Revision: https://reviews.freebsd.org/D22575

Port the NetBSD KCSAN runtime to FreeBSD.

Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in
the FreeBSD kernel. It is a useful tool for finding data races between
threads executing on different CPUs.

This can be enabled by enabling KCSAN in the kernel config, or by using the
GENERIC-KCSAN amd64 kernel. It works on amd64 and arm64, however the later
needs a compiler change to allow -fsanitize=thread that KCSAN uses.

Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22315

attach itwd to the module build on x86

MFC after: 19 days
X-MFC with: r353647

This driver attaches to the Intel VMD drive and connects a new PCI domain
starting at the max. domain, and then work down. Then existing FreeBSD
drivers will attach. Interrupt routing from the VMD MSI-X to the NVME
drive is not well known, so any interrupt is sent to all children that
register.

VROC used Intel meta data so graid(8) works with it. However, graid(8)
supports RAID 0,1,10 for read and write. I have some early code to
support writes with RAID 5. Note that RAID 5 can have life issues
with SSDs since it can cause write amplification from updating the parity
data.

Hot plug support needs a change to skip the following check to work:
if (pcib_request_feature(dev, PCI_FEATURE_HP) != 0) {
in sys/dev/pci/pci_pci.c.

Looked at by: imp, rpokala, bcr
Differential Revision: https://reviews.freebsd.org/D21383

powerpc64/powernv: Add opal NVRAM driver for PowerNV systems

Add a very basic NVRAM driver for OPAL which can be used by the IBM
powerpc-utils nvram utility, not to be confused with the base nvram utility,
which only operates on powermac_nvram.

The IBM utility handles all partitions itself, treating the nvram device as
a plain store.

An alternative would be to manage partitions in the kernel, and augment the
base nvram utility to deal with different backing stores, but that
complicates the driver significantly. Instead, present the same interface
IBM's utlity expects, and we get the usage for free.

Tested by: bdragon

arm64: connect Linuxulator to the build

More work needs to be done, but it is capable of running basic
statically or dynamically linked Linux/arm64 binaries.

Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Add kernel-side support for in-kernel TLS.

KTLS adds support for in-kernel framing and encryption of Transport
Layer Security (1.0-1.2) data on TCP sockets. KTLS only supports
offload of TLS for transmitted data. Key negotation must still be
performed in userland. Once completed, transmit session keys for a
connection are provided to the kernel via a new TCP_TXTLS_ENABLE
socket option. All subsequent data transmitted on the socket is
placed into TLS frames and encrypted using the supplied keys.

Any data written to a KTLS-enabled socket via write(2), aio_write(2),
or sendfile(2) is assumed to be application data and is encoded in TLS
frames with an application data type. Individual records can be sent
with a custom type (e.g. handshake messages) via sendmsg(2) with a new
control message (TLS_SET_RECORD_TYPE) specifying the record type.

At present, rekeying is not supported though the in-kernel framework
should support rekeying.

KTLS makes use of the recently added unmapped mbufs to store TLS
frames in the socket buffer. Each TLS frame is described by a single
ext_pgs mbuf. The ext_pgs structure contains the header of the TLS
record (and trailer for encrypted records) as well as references to
the associated TLS session.

KTLS supports two primary methods of encrypting TLS frames: software
TLS and ifnet TLS.

Software TLS marks mbufs holding socket data as not ready via
M_NOTREADY similar to sendfile(2) when TLS framing information is
added to an unmapped mbuf in ktls_frame(). ktls_enqueue() is then
called to schedule TLS frames for encryption. In the case of
sendfile_iodone() calls ktls_enqueue() instead of pru_ready() leaving
the mbufs marked M_NOTREADY until encryption is completed. For other
writes (vn_sendfile when pages are available, write(2), etc.), the
PRUS_NOTREADY is set when invoking pru_send() along with invoking
ktls_enqueue().

A pool of worker threads (the "KTLS" kernel process) encrypts TLS
frames queued via ktls_enqueue(). Each TLS frame is temporarily
mapped using the direct map and passed to a software encryption
backend to perform the actual encryption.

(Note: The use of PHYS_TO_DMAP could be replaced with sf_bufs if
someone wished to make this work on architectures without a direct
map.)

KTLS supports pluggable software encryption backends. Internally,
Netflix uses proprietary pure-software backends. This commit includes
a simple backend in a new ktls_ocf.ko module that uses the kernel's
OpenCrypto framework to provide AES-GCM encryption of TLS frames. As
a result, software TLS is now a bit of a misnomer as it can make use
of hardware crypto accelerators.

Once software encryption has finished, the TLS frame mbufs are marked
ready via pru_ready(). At this point, the encrypted data appears as
regular payload to the TCP stack stored in unmapped mbufs.

ifnet TLS permits a NIC to offload the TLS encryption and TCP
segmentation. In this mode, a new send tag type (IF_SND_TAG_TYPE_TLS)
is allocated on the interface a socket is routed over and associated
with a TLS session. TLS records for a TLS session using ifnet TLS are
not marked M_NOTREADY but are passed down the stack unencrypted. The
ip_output_send() and ip6_output_send() helper functions that apply
send tags to outbound IP packets verify that the send tag of the TLS
record matches the outbound interface. If so, the packet is tagged
with the TLS send tag and sent to the interface. The NIC device
driver must recognize packets with the TLS send tag and schedule them
for TLS encryption and TCP segmentation. If the the outbound
interface does not match the interface in the TLS send tag, the packet
is dropped. In addition, a task is scheduled to refresh the TLS send
tag for the TLS session. If a new TLS send tag cannot be allocated,
the connection is dropped. If a new TLS send tag is allocated,
however, subsequent packets will be tagged with the correct TLS send
tag. (This latter case has been tested by configuring both ports of a
Chelsio T6 in a lagg and failing over from one port to another. As
the connections migrated to the new port, new TLS send tags were
allocated for the new port and connections resumed without being
dropped.)

ifnet TLS can be enabled and disabled on supported network interfaces
via new '[-]txtls[46]' options to ifconfig(8). ifnet TLS is supported
across both vlan devices and lagg interfaces using failover, lacp with
flowid enabled, or lacp with flowid enabled.

Applications may request the current KTLS mode of a connection via a
new TCP_TXTLS_MODE socket option. They can also use this socket
option to toggle between software and ifnet TLS modes.

In addition, a testing tool is available in tools/tools/switch_tls.
This is modeled on tcpdrop and uses similar syntax. However, instead
of dropping connections, -s is used to force KTLS connections to
switch to software TLS and -i is used to switch to ifnet TLS.

Various sysctls and counters are available under the kern.ipc.tls
sysctl node. The kern.ipc.tls.enable node must be set to true to
enable KTLS (it is off by default). The use of unmapped mbufs must
also be enabled via kern.ipc.mb_use_ext_pgs to enable KTLS.

KTLS is enabled via the KERN_TLS kernel option.

This patch is the culmination of years of work by several folks
including Scott Long and Randall Stewart for the original design and
implementation; Drew Gallatin for several optimizations including the
use of ext_pgs mbufs, the M_NOTREADY mechanism for TLS records
awaiting software encryption, and pluggable software crypto backends;
and John Baldwin for modifications to support hardware TLS offload.

Reviewed by: gallatin, hselasky, rrs
Obtained from: Netflix
Sponsored by: Netflix, Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D21277

Add NTB modules to i386 build.

There is no reason why NTB should not be usable on i386 if memory windows
are small enough.

add superio driver

The goal of this driver is consolidate information about SuperIO chips
and to provide for peaceful coexistence of drivers that need to access
SuperIO configuration registers.

While SuperIO chips can host various functions most of them are
discoverable and accessible without any knowledge of the SuperIO.
Examples are: keyboard and mouse controllers, UARTs, floppy disk
controllers. SuperIO-s also provide non-standard functions such as
GPIO, watchdog timers and hardware monitoring. Such functions do
require drivers with a knowledge of a specific SuperIO.

At this time the driver supports a number of ITE and Nuvoton (fka
Winbond) SuperIO chips.
There is a single driver for all devices. So, I have not done the usual
split between the hardware driver and the bus functionality. Although,
superio does act as a bus for devices that represent known non-standard
functions of a SuperIO chip. The bus provides enumeration of child
devices based on the hardcoded knowledge of such functions. The
knowledge as extracted from datasheets and other drivers.
As there is a single driver, I have not defined a kobj interface for it.
So, its interface is currently made of simple functions.
I think that we can the flexibility (and complications) when we actually
need it.

I am planning to convert nctgpio and wbwd to superio bus very soon.
Also, I am working on itwd driver (watchdog in ITE SuperIO-s).
Additionally, there is ithwm driver based on the reverted sensors
import, but I am not sure how to integrate it given that we still lack
any sensors interface.

Discussed with: imp, jhb
MFC after: 7 weeks
Differential Revision: https://reviews.freebsd.org/D8175

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.

Numerous posts to arch@ and other locations have found no actual users
for this software.

Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745

Add module makefiles for pwm.

Add SDIO support.

Add a CAM-Newbus SDIO support module. This works provides a newbus
infrastructure for device drivers wanting to use SDIO. On the lower end
while it is connected by newbus to SDHCI, it talks CAM using the MMCCAM
framework to get to it.

This also duplicates the usbdevs framework to equally create sdiodev
header files with #defines for "vendors" and "products".

Submitted by: kibab (initial work, see https://reviews.freebsd.org/D12467)
Reviewed by: kibab, imp (comments on earlier version)
MFC after: 6 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19749

Fix several places where tool name has been hardcoded:

install -> ${INSTALL}
mtree -> ${MTREE_CMD}
services_mkdb -> ${SERVICES_MKDB_CMD}
cap_mkdb -> ${CAP_MKDB_CMD}
pwd_mkdb -> ${PWD_MKDB_CMD}
kldxref -> ${KLDXREF_CMD}

If you do custom FreeBSD builds you may want to override those
in some cases.

Sponsored by: Sippy Software, Inc.

LinuxKPI: Finalize move of lindebugfs from ports to base.

The source file was moved to base earlier and also improved upon,
but never compiled in. This patch will:
- Make a module in sys/modules
- Make lindebugfs depend on linuxkpi (for seq_file)
- Check if read/write functions are set before calling, DRM drivers
don't always set both of them.

Reviewed by: hps
Approved by: imp (mentor), hps
MFC after: 1 week

FCP-101: Remove xe(4)

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove wb(4)

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove vx(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove txp(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove tx(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove tl(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove sn(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove sf(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove pcn(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove fe(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove ex(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove ep(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove ed(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove de(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove cs(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

FCP-101: Remove bm(4).

Relnotes: yes
FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md
Reviewed by: jhb, imp
Differential Revision: https://reviews.freebsd.org/D20230

Initial version of Mellanox in-kernel firmware upgrade support.

Submitted by: slavash@
MFC after: 3 days
Sponsored by: Mellanox Technologies

tun/tap: merge and rename to `tuntap`

tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).

This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp

[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).

ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.

(MFC commentary)

This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.

I have no plans to do this MFC as of now.

Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044

Enable Mellanox drivers (modules) on AArch64

Tested by Greg V with mlx5en on an Ampere eMAG instance at Packet.com on
c2.large.arm (with some additional uncommitted PCIe WIP).

PR: 237055
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: hselasky
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19983

Build if_ena.ko on arm64.

This module provides support for the Amazon Elastic Network Adapter; it
was previously only built on x86 architectures, but Amazon EC2 now also
has ARM64 instances with this hardware.

Submitted by: Greg V

Rename fuse(4) to fusefs(4)

This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".

Reviewed by: cem, rgrimes
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19649

Undo accidental part of r344681.

I think I must have accidentally mouse-click pasted while scrolling and
didn't notice it.

Reported by: jhibbits@

Build fdt support modules on systems that use fdt data.

kern.opts.mk sets make var OPT_FDT to a non-empty value if platform.h
contains OPT_FDT.

Modularize xz.

Embedded lzma decompression library becomes a module usable by other
consumers, in addition to geom_uzip.

Most important code changes are
- removal of XZ_DEC_SINGLE define, we need the code to work
with XZ_DEC_DYNALLOC;
- xz_crc32_init() call is removed from geom_uzip, xz module handles
initialization on its own.

xz is no longer embedded into geom_uzip, instead the depend line for
the module is provided, and corresponding kernel option is added to
each MIPS kernel config file using geom_uzip.

The commit also carries unrelated cleanup by removing excess "device geom_uzip"
in places which were missed in r344479.

Reviewed by: cem, hselasky, ray, slavash (previous versions)
Sponsored by: Mellanox Technologies
Differential revision: https://reviews.freebsd.org/D19266
MFC after: 3 weeks

Remove drm2 modules.

Remove support for compiling drm2 as a module. This has transitioned
to the drm-kmod or drm-legacy-kmodw ports.

Approved by: graphics team
Reviewed by: manu@, mmel@
Differential Revision: https://reviews.freebsd.org/D19196

Per discussions on arch@ and elsewhere, retire drm module / drives.

Retire the drm modules / drivers. These are now handled by the
drm-legacy-kmod port and/or the drm-kmod port. All future
development and maintanace will be handled there.

Approved by: graphics team
Reviewed by: manu@, mmel@
Differential Revision: https://reviews.freebsd.org/D19196

Make iflib a loadable module.

iflib is already a module, but it is unconditionally compiled into the
kernel. There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.

Reviewed by: marius
Discussed with: erj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19041

Remove iBCS2, part3: the implementation

Reviewed by: kib (previous version)
Sponsored by: The FreeBSD Foundation

Fix typo in powerpcspe name.

I missed powerpcspe in the previous commit for excluding mps and mpr.
I also learned that 'mips' is overly broad and covers 64bit architectures
too. However, it's not worth the fight right now, so any refinements
will have to come another day.

Remove the mps driver from powerpc 32bit GENERIC, and don't build it and
mpr as a module for powerpc or mips. An upcoming commit will cause these
drivers to rely on the presence of 64bit atomic operations. Discussed
with jhibbits.

Bump to 1300002 for sys/joystick.h removal reversion.

Revert r339563.

I held the mistaken belief this was completely unused. While the
driver is unused and likely not relevant for a long time,
sys/joystick.h lives on in maybe half a dozen ports, even though
hardware to use it hasn't been widely used in maybe 15 years.

Remove the ncr(4) drive.

This driver has been obsolete since the FreeBSD 4.x. It should have
been removed then since the sym(4) driver had subsumed it. The driver
was commented out of GENERIC in 2000.

RelNotes: Yes

Retire scsi_low

scsi_low was a common set of routines to do the SCSI bus sequencing
for the ncv, nsp and stg drivers. Those have been removed, so it's no
longer needed since nothing else in the tree uses it and nothing
likely ever will (it's for super-low-end 8-bit parallel SCSI cards).

Remove stg(4) driver

stg(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame. It was also only enabled on i386.

Relnote: Yes

Remove nsp(4) driver

nsp(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame. It was also only enabled on i386.

Relnote: Yes

Remove ncv(4) driver

ncv(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame..

Relnote: Yes

Retire dpt(4)

Marked as gone in 12 and not relevant since the early 90s. No
sightings in nycbug's dmesg database.

Relnotes: yes

Remove aic(4) driver

aic was marked to be gone in 12 a while ago. Go ahead and remove it.
nycbug's dmesg database shows this was last seen in 6 and one more
time in 4.x. It never was popular, and what popularity it had was over
before the nycbug databse got going in 2004.

Relnotes: yes

Remove aha(4) from the tree.

We tagged aha as gone in 12 a while ago. Proceed with its removal.
Data from nycbug's database shows the last sighting of this driver in
6, with the prior one in 4.x show its popularity had died prior to
4.x.

Relnotes: yes

Remove mse(4) from tree

Remove mse and all support for bus and inport devices from the tree.
Data from nycbug's dmesg database shows the last sighting of this
driver was in 4.10 on only one machine.

Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D17628

Remove joy(4) driver.

This driver was marked as gone in 12. We're at 13 now. Remove it.
Data from nycbug's dmesg cache shows only one potential user,
suggesting it never was used much.

RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D17629

Add amdgpio, driver for GPIO controller on AMD-based x86_64 platforms

Submitted by: Rajesh Kumar <rajbsd@gmail.com>
Differential Revision: https://reviews.freebsd.org/D16865

Add initial driver for ACPI NFIT-enumerated NVDIMMs.

Driver enumerates NVDIMMs. Besides, for each found System Physical
Address (SPA) range, spaN geom provider is created, which allows
formatting and mounting the region as the normal volume. Also,
/dev/nvdimm_spaN node is created, which can be read/written/mapped by
userspace, the mapping is zero-copy.

No support for block access methods implemented, labels are not
parsed. No management interfaces are provided.

Tested by: Intel, NetApp
Sponsored by: The FreeBSD Foundation
Approved by: re (gjb)
MFC after: 2 weeks

ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9)

Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for
FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4).

This commit also re-adds the VF driver to GENERIC since it now compiles and
functions.

The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is
now intended to be used with future products, not just with Fortville/Fort Park
VFs.

A man page update that documents these drivers is forthcoming in a separate
commit.

Reviewed by: sbruno@, kbowling@
Tested by: jeffrey.e.pieper@intel.com
Approved by: re (gjb@)
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D16429

Put building of drm and drm2 modules behind options.

Make the building of drm dependent on MK_MODULE_DRM and the building
of module drm2 on MK_MODULE_DRM2. The defaults are unchanged.

Approved by: re@ (gjb)
Differential Review: https://reviews.freebsd.org/D16894

Remove the Yarrow PRNG algorithm option in accordance with due notice
given in random(4).

This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.

Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.

PR: 230870
Reviewed by: cem
Approved by: so(delphij,gtetlow)
Approved by: re(marius)
Differential Revision: https://reviews.freebsd.org/D16898

Revert drm2 removal.

Revert r338177, r338176, r338175, r338174, r338172

After long consultations with re@, core members and mmacy, revert
these changes. Followup changes will be made to mark them as
deprecated and prent a message about where to find the up-to-date
driver. Followup commits will be made to make this clear in the
installer. Followup commits to reduce POLA in ways we're still
exploring.

It's anticipated that after the freeze, this will be removed in
13-current (with the residual of the drm2 code copied to
sys/arm/dev/drm2 for the TEGRA port's use w/o the intel or
radeon drivers).

Due to the impending freeze, there was no formal core vote for
this. I've been talking to different core members all day, as well as
Matt Macey and Glen Barber. Nobody is completely happy, all are
grudgingly going along with this. Work is in progress to mitigate
the negative effects as much as possible.

Requested by: re@ (gjb, rgrimes)

Remove legacy drm and drm2 from tree

As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.

Users on powerpc, 32-bit hardware, or with GPUs predating Radeon
and i915 will need to install the graphics/drm-legacy-kmod. All
other users should be able to use one of the LinuxKPI-based ports:
graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod.

MFC: never
Approved by: core@

Support building IPMI as a module on powerpc64

This still only supports IPMI via OPAL on powerpc64, but now it can be tested
with a GENERIC kernel.

Make it possible to run ntpd as a non-root user, add ntpd uid and gid.

Code analysis and runtime analysis using truss(8) indicate that the only
privileged operations performed by ntpd are adjusting system time, and
(re-)binding to privileged UDP port 123. These changes add a new mac(4)
policy module, mac_ntpd(4), which grants just those privileges to any
process running with uid 123.

This also adds a new user and group, ntpd:ntpd, (uid:gid 123:123), and makes
them the owner of the /var/db/ntp directory, so that it can be used as a
location where the non-privileged daemon can write files such as the
driftfile, and any optional logfile or stats files.

Because there are so many ways to configure ntpd, the question of how to
configure it to run without root privs can be a bit complex, so that will be
addressed in a separate commit. These changes are just what's required to
grant the limited subset of privs to ntpd, and the small change to ntpd to
prevent it from exiting with an error if running as non-root.

Differential Revision: https://reviews.freebsd.org/D16281

Partial revert of r335399 and r335400:
Unhook the MAC/veriexec, fingerprint handlers, and veriexec modules from
the kernel modules Makefile.

Reviewed by: sjg

Correct linprocfs/linsysfs arch check in r335672

Pointy hat to: emaste

Build linprocfs and linsysfs also on arm64

Sponsored by: Turing Robotic Industries

Device for user space to interface with MAC/veriexec.

The veriexec device features the following ioctl commands:

VERIEXEC_ACTIVE
Activate veriexec functionality
VERIEXEC_DEBUG_ON
Enable debugging mode and increment or set the debug level
VERIEXEC_DEBUG_OFF
Disable debugging mode
VERIEXEC_ENFORCE
Enforce veriexec fingerprinting (and acitvate if not already)
VERIEXEC_GETSTATE
Get current veriexec state
VERIEXEC_LOCK
Lock changes to veriexec meta-data store
VERIEXEC_LOAD
Load veriexec fingerprint if secure level is not raised (and passes the
checks for VERIEXEC_SIGNED_LOAD)
VERIEXEC_SIGNED_LOAD
Load veriexec fingerprints from loader that supports signed manifest
(and thus we can be more lenient about secure level being raised.)
Fingerprints can be loaded if the meta-data store is not locked. Also
securelevel must not have been raised or some fingerprints must have
already been loaded, otherwise it would be dangerous to allow loading.
(Note: this assumes that the fingerprints in the meta-data store at
least cover the fingerprint loader.)

Reviewed by: jtl
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8561

MAC/veriexec implements a verified execution environment using the MAC
framework.

The code is organized into a few distinct pieces:

* The meta-data store (in veriexec_metadata.c) which maps a file system
identifier, file identifier, and generation key tuple to veriexec
meta-data record.

* Fingerprint management (in veriexec_fingerprint.c) which deals with
calculating the cryptographic hash for a file and verifying it. It also
manages the loadable fingerprint modules.

* MAC policy implementation (in mac_veriexec.c) which implements the
following MAC methods:

mpo_init
Initializes the veriexec state, meta-data store, fingerprint modules,
and registers mount and unmount EVENTHANDLERs

mpo_syscall
Implements the following per-policy system calls:
MAC_VERIEXEC_CHECK_FD_SYSCALL
Check a file descriptor to see if the referenced file has a valid
fingerprint.
MAC_VERIEXEC_CHECK_PATH_SYSCALL
Check a path to see if the referenced file has a valid fingerprint.

mpo_kld_check_load
Check if loading a kld is allowed. This checks if the referenced vnode
has a valid fingerprint.

mpo_mount_destroy_label
Clears the veriexec slot data in a mount point label.

mpo_mount_init_label
Initializes the veriexec slot data in a mount point label.
The file system identifier is saved in the veriexec slot data.

mpo_priv_check
Check if a process is allowed to write to /dev/kmem and /dev/mem
devices.
If a process is flagged as trusted, it is allowed to write.

mpo_proc_check_debug
Check if a process is allowed to be debugged. If a process is not
flagged with VERIEXEC_NOTRACE, then debugging is allowed.

mpo_vnode_check_exec
Check is an exectuable is allowed to run. If veriexec is not enforcing
or the executable has a valid fingerprint, then it is allowed to run.
NOTE: veriexec will complain about mismatched fingerprints if it is
active, regardless of the state of the enforcement.

mpo_vnode_check_open
Check is a file is allowed to be opened. If verification was not
requested, veriexec is not enforcing, or the file has a valid
fingerprint, then veriexec will allow the file to be opened.

mpo_vnode_copy_label
Copies the veriexec slot data from one label to another.

mpo_vnode_destroy_label
Clears the veriexec slot data in a vnode label.

mpo_vnode_init_label
Initializes the veriexec slot data in a vnode label.
The fingerprint status for the file is stored in the veriexec slot data.

* Some sysctls, under security.mac.veriexec, for setting debug level,
fetching the current state in a human-readable form, and dumping the
fingerprint database are implemented.

* The MAC policy implementation source file also contains some utility
functions.

* A set of fingerprint modules for the following cryptographic hash
algorithms:
RIPEMD-160, SHA1, SHA2-256, SHA2-384, SHA2-512

* Loadable module builds for MAC/veriexec and fingerprint modules.

WARNING: Using veriexec with NFS (or other network-based) file systems is
not recommended as one cannot guarantee the integrity of the files
served, nor the uniqueness of file system identifiers which are
used as key in the meta-data store.

Reviewed by: ian, jtl
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8554

remove epoch_test from default build

ixl(4): Update to use iflib

Update the driver to use iflib in order to bring performance,
maintainability, and (hopefully) stability benefits to the driver.

The driver currently isn't completely ported; features that are missing:

- VF driver (ixlv)
- SR-IOV host support
- RDMA support

The plan is to have these re-added to the driver before the next FreeBSD release.

Reviewed by: gallatin@
Contributions by: gallatin@, mmacy@, krzysztof.galazka@intel.com
Tested by: jeffrey.e.pieper@intel.com
MFC after: 1 month
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15577

Add modules/rockchip

Build rockchip modules as part of buildkernel.
Add the i2c controller module.

Disable building aesni with base gcc

Because base gcc does not support the required intrinsics, do not
attempt to compile the aesni module with it.

Noticed by: Dan Allen <danallen46@gmail.com>
MFC after: 3 days

Build nvme modules for powerpc, and install man pages

NVMe builds for powerpc now, so just build modules for all powerpc targets,
and install NVMe man pages for all powerpc targets.

ifnet: Replace if_addr_lock rwlock with epoch + mutex

Run on LLNW canaries and tested by pho@

gallatin:
Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5
based ConnectX 4-LX NIC, I see an almost 12% improvement in received
packet rate, and a larger improvement in bytes delivered all the way
to userspace.

When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1,
I see, using nstat -I mce0 1 before the patch:

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32
4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32
4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32
4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32
4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32
4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32
4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32

After the patch

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51
5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51
5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51
5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51
5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52
5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52

Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch

Reviewed by: gallatin
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15366

Retire vxge(4).

This driver was merged to HEAD one week prior to Exar publicly announcing they
had left the Ethernet market. It is not known to be used and has various code
quality issues spotted by Brooks and Hiren. Retire it in preparation for
FreeBSD 12.0.

Submitted by: kbowling
Reviewed by: brooks imp
Relnotes: yes
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15442

allwinner: Add h3 spi driver

This driver is compatible with H3/H5/A64.
Test was done on the OrangePi-PC2 board (H5 based), which have a mx25l1606e
spi flash on it, by writing u-boot image, reading it and booting from the spi.
There is still room for improvement especially on reading using the controller
automatic burst which will avoid us to write dummy data to the TX FIFO.
DMA is also not supported as we currently don't support the DMA controller on
those SoCs
Only add a kernel module for it.

nxge(4):
Remove nxge(4) and associated man page and tools in FreeBSD 12.0.

Submitted by: kbowling
Reviewed by: brooks
Relnotes: yes
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D1529

Retire ixgb(4)

This driver was for an early and uncommon legacy PCI 10GbE for a single
ASIC, Intel 82597EX. Intel quickly shifted to the long lived ixgbe family.

Submitted by: kbowling
Reviewed by: brooks imp jeffrey.e.pieper@intel.com
Relnotes: yes
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15234

Retire lmc(4)

This driver supports legacy, 32-bit PCI devices, and had an ambiguous
license. Supported devices were already reported to be rare in 2003
(when an earlier version of the driver was removed in r123201).

Reviewed by: rgrimes
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15245

martpqi(4):
- Microsemi SCSI driver for PQI controllers.
- Found on newer model HP servers.
- Restrict to AMD64 only as per developer request.

The driver provides support for the new generation of PQI controllers
from Microsemi. This driver is the first SCSI driver to implement the PQI
queuing model and it will replace the aacraid driver for Adaptec Series 9
controllers. HARDWARE Controllers supported by the driver include:

HPE Gen10 Smart Array Controller Family
OEM Controllers based on the Microsemi Chipset.

Submitted by: deepak.ukey@microsemi.com
Relnotes: yes
Sponsored by: Microsemi
Differential Revision: https://reviews.freebsd.org/D14514

Remove support for the Arcnet protocol.

While Arcnet has some continued deployment in industrial controls, the
lack of drivers for any of the PCI, USB, or PCIe NICs on the market
suggests such users aren't running FreeBSD.

Evidence in the PR database suggests that the cm(4) driver (our sole
Arcnet NIC) was broken in 5.0 and has not worked since.

PR: 182297
Reviewed by: jhibbits, vangyzen
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15057

Bring in the Broadcom/Emulex Fibre Channel driver, ocs_fc(4).

The ocs_fc(4) driver supports the following hardware:

Emulex 16/8G FC GEN 5 HBAS
LPe15004 FC Host Bus Adapters
LPe160XX FC Host Bus Adapters

Emulex 32/16G FC GEN 6 HBAS
LPe3100X FC Host Bus Adapters
LPe3200X FC Host Bus Adapters

The driver supports target and initiator mode, and also supports FC-Tape.

Note that the driver only currently works on little endian platforms. It
is only included in the module build for amd64 and i386, and in GENERIC
on amd64 only.

Submitted by: Ram Kishore Vegesna <ram.vegesna@broadcom.com>
Reviewed by: mav
MFC after: 5 days
Relnotes: yes
Sponsored by: Broadcom
Differential Revision: https://reviews.freebsd.org/D11423

Import Blake2 algorithms (blake2b, blake2s) from libb2

The upstream repository is on github BLAKE2/libb2. Files landed in
sys/contrib/libb2 are the unmodified upstream files, except for one
difference: secure_zero_memory's contents have been replaced with
explicit_bzero() only because the previous implementation broke powerpc
link. Preferential use of explicit_bzero() is in progress upstream, so
it is anticipated we will be able to drop this diff in the future.

sys/crypto/blake2 contains the source files needed to port libb2 to our
build system, a wrapped (limited) variant of the algorithm to match the API
of our auth_transform softcrypto abstraction, incorporation into the Open
Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX
accelerated OCF driver, blake2(4).

Optimized variants of blake2 are compiled for a number of x86 machines
(anything from SSE2 to AVX + XOP). On those machines, FPU context will need
to be explicitly saved before using blake2(4)-provided algorithms directly.
Use via cryptodev / OCF saves FPU state automatically, and use via the
auth_transform softcrypto abstraction does not use FPU.

The intent of the OCF driver is mostly to enable testing in userspace via
/dev/crypto. ATF tests are added with published KAT test vectors to
validate correctness.

Reviewed by: jhb, markj
Obtained from: github BLAKE2/libb2
Differential Revision: https://reviews.freebsd.org/D14662

Garbage collect unused chacha20 code

Two copies of chacha20 were imported into the tree on Apr 15 2017 (r316982)
and Apr 16 2017 (r317015). Only the latter is actually used by anything, so
just go ahead and garbage collect the unused version while it's still only
in CURRENT.

I'm not making any judgement on which implementation is better. If I pulled
the wrong one, feel free to swap the existing implementation out and replace
it with the other code (conforming to the API that actually gets used in
randomdev, of course). We only need one generic implementation.

Sponsored by: Dell EMC Isilon

[chvgpio] add GPIO driver for Intel Z8xxx SoC family

Add chvgpio(4) driver for Intel Z8xxx SoC family. This product
was formerly known as Cherry Trail but Linux and OpenBSD drivers
refer to it as Cherry View. This driver is derived from OpenBSD
one so the name is kept for alignment with another BSD system.

Submitted by: Tom Jones <tj@enoti.me>
Reviewed by: gonzo, wblock(man page)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13086

Add modules/spi as a gathering point for SPI-related modules, analagous to
modules/i2c for i2c/iicbus modules. Build spibus as a module.

Build modules specific to imx5/imx6 only when building those kernels.

This adds sys/modules/imx with a SUBDIR makefile to make the whole
collection of modules that are specific to these SoCs. Initially, that
"whole collection" consists of the if_ffec and imx_i2c drivers.

The if_ffec driver is referenced in its existing home in ../ffec rather
than moving it into the imx directory, because it's used by powerpc too,
but it is no longer built for all armv6/7 systems.

The imx_i2c driver is newly added as a module.

Import the mthca kernel side infiniband driver from Linux 4.9 and fix
compilation under FreeBSD. The mthca driver was temporarily removed as
part of the Linux 4.9 RoCE/infinband upgrade.

Top commit in Linux source tree:
69973b830859bc6529a7a0468ba0d80ee5117826

Sponsored by: Mellanox Technologies

bwn(4): migrate bwn(4) to the native bhnd(9) interface, and drop siba_bwn.

- Remove the shim interface that allowed bwn(4) to use either siba_bwn or
bhnd(4), replacing all siba_bwn calls with their bhnd(4) bus equivalents.
- Drop the legay, now-unused siba_bwn bus driver.
- Clean up bhnd(4) board flag defines referenced by bwn(4).

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13518

Add a skeleton Clock Manager for RPi2/3, and use that from pwm
instead of frobbing the registers directly.

As a hack the bcm2835_pwm kmod presently ignores the 'status="disabled"'
in the RPI3 DTB, assuming that if you load the kld you probably
want the PWM to work.

Rename rpi_pwm to bcm283x_pwm, and build it on armv[67] and arm64.

Truncate ratio if period is lowered.

Tested on Rpi2 and Rpi3.

Rpi3 requires DTB->DTS->edit->DTB hack

Unbreak i386 build

The logical result of a right shift >= the width of a type is zero, but our
compiler decides this is a warning (and thus, error). Just remove ccp(4)
from i386.

Reported by: cy
Sponsored by: Dell EMC Isilon

Add ccp(4): experimental driver for AMD Crypto Co-Processor

* Registers TRNG source for random(4)
* Finds available queues, LSBs; allocates static objects
* Allocates a shared MSI-X for all queues. The hardware does not have
separate interrupts per queue. Working interrupt mode driver.
* Computes SHA hashes, HMAC. Passes cryptotest.py, cryptocheck tests.
* Does AES-CBC, CTR mode, and XTS. cryptotest.py and cryptocheck pass.
* Support for "authenc" (AES + HMAC). (SHA1 seems to result in
"unaligned" cleartext inputs from cryptocheck -- which the engine
cannot handle. SHA2 seems to work fine.)
* GCM passes for block-multiple AAD, input lengths

Largely based on ccr(4), part of cxgbe(4).

Rough performance averages on AMD Ryzen 1950X (4kB buffer):
aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s
ccp: ~630 Mb/s SHA256: ~660 Mb/s SHA512: ~700 Mb/s
cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s

As you can see, performance is poor in comparison to aesni(4) and even
cryptosoft (due to high setup cost). At a larger buffer size (128kB),
throughput is a little better (but still worse than aesni(4)):

aesni: SHA1:~10400 Mb/s SHA256: ~9950 Mb/s
ccp: ~2200 Mb/s SHA256: ~2600 Mb/s SHA512: ~3800 Mb/s
cryptosoft: ~1750 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s

AES performance has a similar story:

aesni: 4kB: ~11250 Mb/s 128kB: ~11250 Mb/s
ccp: ~350 Mb/s 128kB: ~4600 Mb/s
cryptosoft: ~1750 Mb/s 128kB: ~1700 Mb/s

This driver is EXPERIMENTAL. You should verify cryptographic results on
typical and corner case inputs from your application against a known- good
implementation.

Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12723

Move i386/isa/elink.[hc] to dev/ep.

The ep(4) driver is the only consumer of the two functions from
elink.c. I removed the standalone module as well, and most likely,
the module metadata is not needed anywhere, but this is for later
cleanup.

Discussed with: imp, jhb
Sponsored by: The FreeBSD Foundation

Port cloudabi32.ko to FreeBSD/arm64.

This change adds an implementation of a sysent for running CloudABI
armv6 and armv7 binaries on FreeBSD/arm64. It is a somewhat literal copy
of the armv6 version, except that it's been patched up to use the proper
registers.

Just like for cloudabi32.ko on FreeBSD/amd64, we make use of a vDSO that
automatically pads system call parameters to 64-bit value. These are
stored in a buffer on the stack, meaning we need to use copyin() and
copyout() unconditionally.

Remove no longer supported mthca driver.

Sponsored by: Mellanox Technologies

Enable i386 build of the Cavium LiquidIO driver (lio) module.

Submitted by: pkanneganti@cavium.com (Prasad V Kanneganti)
MFC after: 1 week
Sponsored by: Cavium Networks
Differential Revision: https://reviews.freebsd.org/D12415

Remove mbpool(9) now that it has no consumers.

mbpool existed to support NICs with memory interfaces and all remaining
comsumers were removed earlier this year with NATM.

Reviewed by: jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10513

Support the EFI Runtime Services on arm64. As with amd64 we use the 1:1
mapping. This uses the new common code shared with amd64.

The RTC should only be accessed via EFI. There is no locking around it as
the spec only has this as a requirement for the PC-AT CMOS device.

Reviewed by: kib, imp
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12595

Support armv7 builds for userland

Make armv7 as a new MACHINE_ARCH.

Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.

Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).

Add armv7 to the universe build.

Differential Revision: https://reviews.freebsd.org/D12010

Don't (try to) build lio(4) if the SOURCELESS_UCODE is set.

Submitted by: Fabien Keil <fk@fabiankeil.de>

qlnx: exclude if WITHOUT_SOURCELESS_UCODE set

PR: 222277
Submitted by: Fabian Keil
Obtained from: ElectroBSD
MFC after: 1 week

The diff is the initial submission of Cavium Liquidio 2350/2360 10/25G
Intelligent NIC driver.

The submission conconsists of firmware binary file and driver sources.

Submitted by: pkanneganti@cavium.com (Prasad V Kanneganti)
Relnotes: Yes
Sponsored by: Cavium Networks
Differential Revision: https://reviews.freebsd.org/D11927

Add smn(4) driver for AMD System Management Network

AMD Family 17h CPUs have an internal network used to communicate between
the host CPU and the PSP and SMU coprocessors. It exposes a simple
32-bit register space.

Reviewed by: avg (no +1), mjoras, truckman
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12217

Add new mlx5ib(4) driver to the kernel source tree which supports
Remote DMA over Converged Ethernet, RoCE, for the ConnectX-4 series of
PCI express network cards.

There is currently no user-space support and this driver only supports
kernel side non-routable RoCE V1. The krping kernel module can be used
to test this driver. Full user-space support including RoCE V2 will be
added as part of the ongoing upgrade to ibcore from Linux 4.9. Otherwise
this driver is feature equivalent to mlx4ib(4). The mlx5ib(4) kernel
module will only be built when WITH_OFED=YES is specified.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

sys/modules: don't build qlxgbe if the user objects to sourceless ucode

PR: 204749
Submitted by: Fabian Keil
Obtained from: ElectroBSD
MFC after: 1 week

sys/modules: don't build bxe if the user objects to sourceless ucode

PR: 204747
Submitted by: Fabian Keil
Obtained from: ElectroBSD
MFC after: 1 week

Add support for Intel Software Guard Extensions (Intel SGX).

Intel SGX allows to manage isolated compartments "Enclaves" in user VA
space. Enclaves memory is part of processor reserved memory (PRM) and
always encrypted. This allows to protect user application code and data
from upper privilege levels including OS kernel.

This includes SGX driver and optional linux ioctl compatibility layer.
Intel SGX SDK for FreeBSD is also available.

Note this requires support from hardware (available since late Intel
Skylake CPUs).

Many thanks to Robert Watson for support and Konstantin Belousov
for code review.

Project wiki: https://wiki.freebsd.org/Intel_SGX.

Reviewed by: kib
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11113

Reconnect mmc and mmcsd disconnected unintentioanlly in mmccam commit.

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers from both the kernel and as
userland daemons are possible, though much of that functionality will
come later.

Some of the CAM integration isn't complete (there are sleeps in the
device probe state machine, for example), but those minor issues can
be improved in-tree more easily than out of tree and shouldn't gate
progress on other fronts. Appologies to reviews if specific items
have been overlooked.

Submitted by: Ilya Bakulin
Reviewed by: emaste, imp, mav, adrian, ian
Differential Review: https://reviews.freebsd.org/D4761

merge with first commit, various compile hacks.

Allow building if_ffec as a module.

[ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.

In the deep past, when this code compiled as a binary module, ath_hal
built as a module. This allowed custom, smaller HAL modules to be built.
This was especially beneficial for small embedded platforms where you
didn't require /everything/ just to run.

However, sometime around the HAL opening fanfare, the HAL landed here
as one big driver+HAL thing, and a lot of the (dirty) infrastructure
(ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away.
This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't
really floated up to the modules themselves.

I'm now in a position where for the reaaaaaly embedded boards (both the
really old and the last couple generation of QCA MIPS boards) having a
cut down HAL module and driver loaded at runtime is /actually/ beneficial.

This reduces the kernel size down by quite a bit. The MIPS modules look
like this:

adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko
-r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko
-r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko
-r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko
-r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko
-r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko

And the x86 versions, like this:

root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko
-r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko
-r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko
-r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko
-r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko
-r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko
-r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko
-r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko
-r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko
-r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko

.. so you can see, not building the whole HAL can save quite a bit.
For example, if you don't need AR9300 support, you can actually avoid
wasting half a megabyte of RAM. On embedded routers this is quite a
big deal.

The AR9300 HAL can be later further shrunk because, hilariously,
it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support.
(I'll chase that down later as it's quite a big savings if you're only
building for a single embedded target.)

So:

* Create a very hackish way to load/unload HAL modules
* Create module metadata for each HAL subtype - ah_osdep_arXXXX.c
* Create module metadata for ath_rate and ath_dfs (bluetooth is
currently just built as part of it)
* .. yes, this means we could actually build multiple rate control
modules and pick one at load time, but I'd rather just glue this
into net80211's rate control code. Oh well, baby steps.
* Main driver is now "ath_main"
* Create an "if_ath" module that does what the ye olde one did -
load PCI glue, main driver, HAL and all child modules.
In this way, if you have "if_ath_load=YES" in /boot/modules.conf
it will load everything the old way and stuff should still work.
* For module autoloading purposes, I actually /did/ fix up
the name of the modules in if_ath_pci and if_ath_ahb.

If you want to selectively load things (eg on ye cheape ARM/MIPS platforms
where RAM is at a premium) you should:

* load ath_hal
* load the chip modules in question
* load ath_rate, ath_dfs
* load ath_main
* load if_ath_pci and/or if_ath_ahb depending upon your particular
bus bind type - this is where probe/attach is done.

TODO:

* AR5312 module and associated pieces - yes, we have the SoC side support
now so the wifi support would be good to "round things out";
* Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet
structures; this'll simplify other things.
* Should add a simple refcnt thing to the HAL RF/chip modules so you
can't unload them whilst you're using them.
* Manpage updates, UPDATING if appropriate, etc.

Add support for Amazon Elastic Network Adapter (ENA) NIC

ENA is a networking interface designed to make good use of modern CPU
features and system architectures.

The ENA device exposes a lightweight management interface with a
minimal set of memory mapped registers and extendable command set
through an Admin Queue.

The driver supports a range of ENA devices, is link-speed independent
(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has
a negotiated and extendable feature set.

Some ENA devices support SR-IOV. This driver is used for both the
SR-IOV Physical Function (PF) and Virtual Function (VF) devices.

ENA devices enable high speed and low overhead network traffic
processing by providing multiple Tx/Rx queue pairs (the maximum number
is advertised by the device via the Admin Queue), a dedicated MSI-X
interrupt vector per Tx/Rx queue pair, and CPU cacheline optimized
data placement.

The ENA driver supports industry standard TCP/IP offload features such
as checksum offload and TCP transmit segmentation offload (TSO).
Receive-side scaling (RSS) is supported for multi-core scaling.

The ENA driver and its corresponding devices implement health
monitoring mechanisms such as watchdog, enabling the device and driver
to recover in a manner transparent to the application, as well as
debug logs.

Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds. This feature will
be implemented for driver in future releases.

Submitted by: Michal Krawczyk <mk@semihalf.com>
Jakub Palider <jpa@semihalf.com>
Jan Medala <jan@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon.com Inc.
Differential revision: https://reviews.freebsd.org/D10427

Only compile tests/ if MK_TESTS != no or ALL_MODULES is defined

MFC after: 3 weeks
Sponsored by: Dell EMC Isilon

Remove the NATM framework including the en(4), fatm(4), hatm(4), and
patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).

With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.

Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.

Reviewed by: philip
Approved by: harti

3BSD-licensed implementation of the chacha20 stream cipher, intended for
use by the upcoming arc4random replacement.

Add 25/40/100Gigabit Ethernet Driver version v1.3.0 for Cavium Inc's.
Qlogic 45000 Series Adapters

MFC after:2 weeks

Add ipfw_pmod kernel module.

The module is designed for modification of a packets of any protocols.
For now it implements only TCP MSS modification. It adds the external
action handler for "tcp-setmss" action.

A rule with tcp-setmss action does additional check for protocol and
TCP flags. If SYN flag is present, it parses TCP options and modifies
MSS option if its value is greater than configured value in the rule.
Then it adjustes TCP checksum if needed. After handling the search
continues with the next rule.

Obtained from: Yandex LLC
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Yandex LLC
No objection from: #network
Differential Revision: https://reviews.freebsd.org/D10150

Split iscsi(4) ctl frontend off of ctl(4) as cfiscsi(4)

The goal of this work is to remove the explicit dependency for ctl(4)
on iscsi(4), so end-users without iscsi(4) support in the kernel can
use ctl(4) for its other functions.

This allows those without iscsi(4) support built into the kernel to use
ctl(4) as a test mechanism. As a sidenote, this was possible around the
10.0-RELEASE period, but made impossible for end-users without iscsi(4)
between 10.0-RELEASE and 11.0-RELEASE.

Automatically load cfiscsi(4) from ctladm(8) and ctld(8) for backwards
compatibility with previously releases. The automatic loading feature is
compiled into the beforementioned tools if MK_ISCSI == yes when building
world.

Add a manpage for cfiscsi(4) and refer to it in ctl(4).

Differential Revision: D10099
MFC after: 2 months
Relnotes: yes
Reviewed by: mav, trasz
Sponsored by: Dell EMC Isilon

Tweak the Makefiles a bit to allow using "tcp" in MODULES_OVERRIDE
to build the tcp modules.

Sponsored by: Netflix, Inc.

[spigen] Add spigen module

spigen provides userland API to SPI bus. Make it available as a loadable
module so people using official ARM images can enabled it on devices like
BBB or RPi without re-building kernel

MFC after: 1 week

sys/modules: normalize .CURDIR-relative paths to SRCTOP

This simplifies make output/logic

Tested with: `cd sys/modules; make ALL_MODULES=` on amd64
MFC after: 1 month
Sponsored by: Dell EMC Isilon

add a module that provides support for DRAM ECC error injection on AMD CPUs

I imagine that the module would be useful only to a very limited number
of developers, so that's my excuse for not writing any documentation.
On a more serious note, please see DRAM Error Injection section of BKDGs
for families 10h - 16h. E.g. section 2.13.3.1 of BKDG for AMD Family 15h
Models 00h-0Fh Processors.

Many thanks to kib for his suggestions and comments.

Discussed with: kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D9824

Remove SVR4 (System V Release 4) binary compatibility support.

UNIX System V Release 4 is operating system released in 1988. It ceased
to exist in early 2000-s.

Remove the ahb driver for the EISA Adaptec 174x.

Merge projects/ipsec into head/.

Small summary
-------------

o Almost all IPsec releated code was moved into sys/netipsec.
o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel
option IPSEC_SUPPORT added. It enables support for loading
and unloading of ipsec.ko and tcpmd5.ko kernel modules.
o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by
default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type
support was removed. Added TCP/UDP checksum handling for
inbound packets that were decapsulated by transport mode SAs.
setkey(8) modified to show run-time NAT-T configuration of SA.
o New network pseudo interface if_ipsec(4) added. For now it is
build as part of ipsec.ko module (or with IPSEC kernel).
It implements IPsec virtual tunnels to create route-based VPNs.
o The network stack now invokes IPsec functions using special
methods. The only one header file <netipsec/ipsec_support.h>
should be included to declare all the needed things to work
with IPsec.
o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed.
Now these protocols are handled directly via IPsec methods.
o TCP_SIGNATURE support was reworked to be more close to RFC.
o PF_KEY SADB was reworked:
- now all security associations stored in the single SPI namespace,
and all SAs MUST have unique SPI.
- several hash tables added to speed up lookups in SADB.
- SADB now uses rmlock to protect access, and concurrent threads
can do SA lookups in the same time.
- many PF_KEY message handlers were reworked to reflect changes
in SADB.
- SADB_UPDATE message was extended to support new PF_KEY headers:
SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They
can be used by IKE daemon to change SA addresses.
o ipsecrequest and secpolicy structures were cardinally changed to
avoid locking protection for ipsecrequest. Now we support
only limited number (4) of bundled SAs, but they are supported
for both INET and INET6.
o INPCB security policy cache was introduced. Each PCB now caches
used security policies to avoid SP lookup for each packet.
o For inbound security policies added the mode, when the kernel does
check for full history of applied IPsec transforms.
o References counting rules for security policies and security
associations were changed. The proper SA locking added into xform
code.
o xform code was also changed. Now it is possible to unregister xforms.
tdb_xxx structures were changed and renamed to reflect changes in
SADB/SPDB, and changed rules for locking and refcounting.

Reviewed by: gnn, wblock
Obtained from: Yandex LLC
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D9352

Fix compilation for mips64 platforms

The hwpmc_mips24k / hwpmc_mips74k modules are only for mips 32-bit hosts.
Reviewed by: adrian

Fix compilation!

[mips] add some (temporary, I hope!) mips24k/mips74k hwpmc modules.

Ideally we'd have a top level hwpmc module with the shared bits, then
cpu specific glue as needed. However, on the MIPS side, there's no
probe code - {mips24k, mips74k, octeon} implement a set of methods
that hwpmc_mips.c expects.

So this populates separate modules with duplicate code.
Ew, but it does work.

This gets me off the hook - these work fine as copied into the relevant
mfsroot for mips24k/mips74k systems.

TODO:

* do it the "right" way in the future. Note that modules/hwpmc/ does
build fine on MIPS, it jusn't DO anything. So it'd be nice to
maybe call that "hwpmc_core" and then "hwpmc" can be the CPU/arch glue.

Garbage collect pc98-only variables still referenced in sys/modules/Makefile

These should have been removed with r312910

Remove duplicate bhnd SUBDIR entry

MFC after: 1 week
PR: 216413
Reported by: mail@fbsd.e4m.org

Remove pc98 support completely.
I thank all developers and contributors for pc98.

Relnotes: yes

mips: exclude modules that fail to build

Disconnect netfpga10g module from the build

It only builds with the non-default DEVICE_POLLING option.

Approved by: bz

[sdhci] Add ACPI platform support for SDHCI driver

- Create ACPI version of SDHCI attach/detach/accessors logic. Some
platforms (e.g. BayTrail-based Minnowboard) expose SDHCI devices
via ACPI, not PCI
- Add sdchi_acpi kernel module

Reviewed by: ian, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9112

Migrate e1000 to the IFLIB framework:
- em(4) igb(4) and lem(4)
- deprecate the igb device from kernel configurations
- create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko

Devices tested:
- 82574L
- I218-LM
- 82546GB
- 82579LM
- I350
- I217

Please report problems to freebsd-net@freebsd.org

Partial review from jhb and suggestions on how to *not* brick folks who
originally would have lost their igbX device.

Submitted by: mmacy@nextbsd.org
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Limelight Networks and Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8299

[intelspi] Add SPI driver for Intel BayTrail SoC

Add SPI mode (PIO-only) support for Intel Synchronous Serial Port that
can be found in several Intel's products starting from PXA family.
Most of implementations have slight differences in behavior and in
addresses for registers subset. This driver covers only BayTrail SoC
implementation for it's the only hardware I have to test it on.

Driver attaches to ACPI bus only and does not have PCI or FDT support
for now due to lack of hardware to test it on.

"intelspi" is the best name I've managed to come up with. Linux driver
name (spi-pxa2xx) does not make sense because current implementation
does not support actual PXA2xx SoCs. And as far as I know there is no
codename assigned to Intel SSP chip.

Reviewed by: br, manu
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D8896

Build smbios.ko as a module for amd64 and i386

For whatever reason, smapi, smbios, vpd are all under the "bios" directory.
smapi is only for i386, so the entire "bios" directory is only built for
i386. Break smapi out, and make only it i386-specific. Then, build the
"bios" directory for both amd64 and i386.

Reviewed by: imp
MFC after: 1 week
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D8609

[bytgpio] Fix pc98 build by disabling bytgpio module for this platform

Reported by: dim

[bytgpio] Add module for bytgpio(4)

MFC after: 3 days