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
This is the server (target in SCSI terms) for NVMe over Fabrics.
Userland is responsible for accepting a new queue pair and receiving
the initial Connect command before handing the queue pair off via an
ioctl to this CTL frontend.
This frontend exposes CTL LUNs as NVMe namespaces to remote hosts.
Users can ask LUNS to CTL that can be shared via either iSCSI or
NVMeoF.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44726
This is the client (initiator in SCSI terms) for NVMe over Fabrics.
Userland is responsible for creating a set of queue pairs and then
handing them off via an ioctl to this driver, e.g. via the 'connect'
command from nvmecontrol(8). An nvmeX new-bus device is created
at the top-level to represent the remote controller similar to PCI
nvmeX devices for PCI-express controllers.
As with nvme(4), namespace devices named /dev/nvmeXnsY are created and
pass through commands can be submitted to either the namespace devices
or the controller device. For example, 'nvmecontrol identify nvmeX'
works for a remote Fabrics controller the same as for a PCI-express
controller.
nvmf exports remote namespaces via nda(4) devices using the new NVMF
CAM transport. nvmf does not support nvd(4), only nda(4).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44714
Structurally this is very similar to the TCP transport for iSCSI
(icl_soft.c). One key difference is that NVMeoF transports use a more
abstract interface working with NVMe commands rather than transport
PDUs. Thus, the data transfer for a given command is managed entirely
in the transport backend.
Similar to icl_soft.c, separate kthreads are used to handle transmit
and receive for each queue pair. On the transmit side, when a capsule
is transmitted by an upper layer, it is placed on a queue for
processing by the transmit thread. The transmit thread converts
command response capsules into suitable TCP PDUs where each PDU is
described by an mbuf chain that is then queued to the backing socket's
send buffer. Command capsules can embed data along with the NVMe
command.
On the receive side, a socket upcall notifies the receive kthread when
more data arrives. Once enough data has arrived for a PDU, the PDU is
handled synchronously in the kthread. PDUs such as R2T or data
related PDUs are handled internally, with callbacks invoked if a data
transfer encounters an error, or once the data transfer has completed.
Received capsule PDUs invoke the upper layer's capsule_received
callback.
struct nvmf_tcp_command_buffer manages a TCP command buffer for data
transfers that do not use in-capsule-data as described in the NVMeoF
spec. Data related PDUs such as R2T, C2H, and H2C are associated with
a command buffer except in the case of the send_controller_data
transport method which simply constructs one or more C2H PDUs from the
caller's mbuf chain.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44712
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
This includes functions to validate NVMe Qualified Names, compute an
initial value of the CAP property, validate changes to the CC
property, and populate the Identify Controller data structure for an
I/O controller.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44709
- Helper macros for specific SGL types used with the TCP transport
- An inline function which validates various fields in TCP PDUs
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44708
This defines structures, ioctl commands, and related constants used
for both the Fabrics host and controller.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44706
- Add opcode, command structure, and new error code for Disconnect
fabrics opcode.
- Add a generic struct nvmf_fabric_command.
- Add constants for special controller ID values.
- Add constants for the cattr field in the Connect command and the
default value for the kato field in the Connect command.
- Add constants for the offset of controller properties (Fabrics
version of controller registers).
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44705
- Replace SPDK_STATIC_ASSERT with _Static_assert.
- Remove SPDK_ and spdk_ prefixes from types and constants.
- Switch to using FreeBSD headers, e.g. <dev/nvme/nvme.h> in place of
"spdk/nvme_spec.h".
- Add a definition of NVME_NQN_FIELD_SIZE (from SPDK's nvme_spec.h).
- Remove constant for the fabrics opcode as this is already present in
<dev/nvme/nvme.h>.
- Use types from <dev/nvme/nvme.h> for NVMe structures including
struct nvme_sgl_descriptor, struct nvme_command, and
struct nvme_completion.
- Use plain uint16_t in place of struct spdk_nvme_status.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44704
This is a copy of spdk/include/spdk/nvmf_spec.h as of commit
470e851852bb948334a272c9f8de495020fa082f from Intel's SPDK.
Subsequent commits will modify it to be suitable header for the
kernel, but importing the stock file first makes it easier to see
how the resulting header is derived from the original.
Reviewed by: imp
Obtained from: SPDK (https://github.com/spdk/spdk.git)
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44703
This affects TOE operation when multiple rx c-channels are in use for
offload, which is an unusual configuration.
MFC after: 1 week
Sponsored by: Chelsio Communications
It is the equivalent of tx_chan but for receive so rx_chan is a better
name. Initialize both using helper functions and make sure both are
displayed in the sysctl MIB.
MFC after: 1 week
Sponsored by: Chelsio Communications
PORTVEC obtained from the firmware is the authoritative source of this
information, and nports (calculated from PORTVEC) is available by the
time t4_port_init runs.
MFC after: 1 week
Sponsored by: Chelsio Communications
In cd85379104, kib made maxphys a load-time tunable. This made
the #define MAXPHYS in sys/param.h almost entirely obsolete, as
it could now be overridden by kern.maxphys at boot time, or by
opt_maxphys.h.
However, decades of tradition have led to several new, incorrect, uses
of MAXPHYS in other parts of the kernel, mostly by seasoned
developers. I've corrected those uses here in a mechanical fashion,
and verified that it fixes a bug in the md driver that I was
experiencing.
Since using MAXPHYS is such an easy mistake to make, it is best to
hide it from the kernel namespace. So I've moved its definition to
_maxphys.h, which is now included in param.h only for userspace.
That brings up the fact that lots of userspace programs use MAXPHYS
for different reasons, most of them probably wrong. Userspace consumers
that really need to know the value of maxphys should probably be
changed to use the kern.maxphys sysctl. But that's outside the scope
of this change.
Reviewed by: imp, jkim, kib, markj
Fixes: 30038a8b4e ("md: Get rid of the pbuf zone")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44986
All the channels are not used on all boards and there's no point
allocating taskqueues that will never be used.
MFC after: 1 week
Sponsored by: Chelsio Communications
The firmware clears the interrupts already and it has a better idea of
exactly what to clear for which generation of the ASIC. There is no
need for the driver to get involved.
MFC after: 1 week
Sponsored by: Chelsio Communications
Hook in RSS glue.
Default to "off" for the split header feature to ensure netmap
compatibility.
Change the PCS indirection register values based on hardware type
(ported from Linux).
Move tunable settings to sysctl_init() and set the defaults there.
Ensure it's called at the right time by moving it back.
Reset PHY RX data path when mailbox command times out (Ported from
Linux).
Check if VLAN HW tagging is enabled before assuming a VLAN tag
is present in a descriptor.
Disable the hardware filter since multicast traffic is dropped
in promisc mode.
Remove unnecessary return statement.
Missing sfp_get_mux, causing a race between ports to read
SFP(+) sideband signals.
Validate and fix incorrectly initialized polarity/configuration
registers.
Remove unnecessary SFP reset.
axgbe_isc_rxd_pkt_get has no error state, remove unnecessary
big packet check.
Enable RSF to prevent zero-length packets while in Netmap mode.
DMA cache coherency update (ported from Linux).
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1103
This check is not related to channel initializion, but is also
unnecessary, since sysctl_hw_snd_timeout() takes care of checking if
chn_timeout is within bounds.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44992
Improve code layering. These are channel functions, and so they do not
belong in pcm/sound.c.
While here, assert in chn_ref() that new refcount won't be negative.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44985
pcm_chn_destroy() acts like a wrapper around chn_kill(), and
additionally calls a few more functions that should in fact be part of
chn_kill()'s logic. Merge pcm_chn_destroy()'s functionality in
chn_kill() to improve readability, as well as code layering.
While here, convert chn_kill() to void as it currently always returns 0.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44984
The unit.* code is largely obsolete and imposes limits that are no
longer needed nowadays.
- Capping the maximum allowed soundcards in a given machine. By default,
the limit is 512 (snd_max_u() in unit.c), and the maximum possible is
2048 (SND_UNIT_UMAX in unit.h). It can also be tuned through the
hw.snd.maxunit loader(8) tunable. Even though these limits are large
enough that they should never cause problems, there is no need for
this limit to exist in the first place.
- Capping the available device/channel types. By default, this is 32
(snd_max_d() in unit.c). However, these types are pre-defined in
pcm/sound.h (see SND_DEV_*), so the cap is unnecessary when we know
that their number is constant.
- Capping the number of channels per-device. By default, the limit 1024
(snd_max_c() in unit.c). This is probably the most problematic of the
limits mentioned, because this limit can never be reached, as the
maximum is hard-capped at either hw.snd.maxautovchans (16 by default),
or SND_MAXHWCHAN and SND_MAXVCHANS.
These limtits are encoded in masks (see SND_U_MASK, SND_D_MASK,
SND_C_MASK in unit.h) and are used to construct a bitfield of the form
[dsp_unit, type, channel_unit] in snd_mkunit() which is assigned to
pcm_channel->unit.
This patch gets rid of everything unit.*-related and makes a slightly
different use of the "unit" field to only contain the channel unit
number. The channel type is stored in a new pcm_channel->type field, and
the DSP unit number need not be stored at all, since we can fetch it
from device_get_unit(pcm_channel->dev). This change has the effect that
we no longer need to impose caps on the number of soundcards,
device/channel types and per-device channels. As a result the code is
noticeably simplified and more readable.
Apart from the fact that the hw.snd.maxunit loader(8) tunable is also
retired as a side-effect of this patch, sound(4)'s behavior remains the
same.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D44912
Currently we are force-destroying all channels unconditionally in
pcm_killchan(). However, since asynchronous audio device detach is
possible as of 44e128fe9d, if we do not check whether the channel is
sleeping or not and forcefully kill it, we will get a panic from
cv_timedwait_sig() (called from chn_sleep()), because it will try to use
a freed lock/cv.
Modify pcm_killchan() (renamed to pcm_killchans() since that's a more
appropriate name now) to loop through the channel list and destroy only
the channels that are awake, otherwise wake up the sleeping thread and
try again. This loop is repeated until all channels are awakened and
destroyed.
To reduce code duplication, implement chn_shutdown() which wakes up the
channel and sets CHN_F_DEAD, and use it in pcm_unregister() and
pcm_killchans().
Reported by: KASAN
Fixes: 44e128fe9d ("sound: Implement asynchronous device detach")
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44923
Make sure that the softc isn't freed in between the checks.
Sponsored by: The FreeBSD Foundation
MFC after; 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44991
If we only have a single soundcard attached and we detach it right
before entering [dsp|mixer]_clone(), there is a chance pcm_unregister()
will have returned already, meaning it will have set snd_unit to -1, and
thus devclass_get_softc() will return NULL here.
While here, 1) move the calls to dsp_destroy_dev() and mixer_uninit()
below the point where we unset SD_F_REGISTERED, and 2) follow what
mixer_clone() does and make sure we don't use a NULL d->dsp_dev in
dsp_clone().
Reported by: KASAN
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44924
At least for HDSPe RayDAT cards, newer firmware comes with RME's own PCI
vendor id instead of the Xilinx one. Other HDSPe cards are probably also
affected. Update snd_hdspe(4) to recognize both the old Xilinx and the
new RME vendor ids.
Differential Revision: https://reviews.freebsd.org/D44978
MFC after: 1 day
When disabling a lun there can still be outstanding AIOs and INOTs, when
this happens previously the lun would just fail to disable and trying to
re-use the lun would break the card.
isp(4) in target mode does the same thing when disabling a lun, in
testing this allows re-starting of ctld(8) with connected initiators and
allows initiators to gracefully resume afterwards.
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/1190
Linux removed theirs starting in 2018 in commit:
"scsi: aic7xxx: Fix build using bare-metal toolchain"
Also remove now-useless sys/cdefs.h includes
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav, emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/1189
Several users with alc(4)-based "Killer" Ethernet cards have reported
issues with this driver not passing traffic, which are solved by
disabling MSI-X using the provided tunable.
To work around this issue, disable MSI-X by default on this card.
This is done by having msix_disable default to 2, which means
"auto-detect". The user can still override this to either 0 or 1 as
desired.
Since these are slow (1Gbps) Ethernet ICs used in low-end systems, it's
unlikely this will cause any practical performance issues; on the other
hand, the card not working by default likely causes issues for many new
FreeBSD users who find their network port doesn't work and have no idea
why.
PR: 230807
MFC after: 1 week
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1185
One of the comments in ahc_execute_scb() notes that the CAM direction is
actually w.r.t. the initiator. As a consequence, all of our sync ops
end up being wrong because the direction is flipped from that of the
transfer. Fix it to do proper invalidation and avoid spewing random
garbage out on the SCSI bus.
Reported and tested by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
Differential Revision: https://reviews.freebsd.org/D44860
In ahc_init(), qoutfifo is already assigned to effectively the same
value a couple lines up, except in the first assignment it uses the
proper definition; keep the more descriptive assignment.
ahc_targetcmd_offset() gets the offset wrong entirely; as per the
area of ahc_init() this diff also touches, targetcmds is laid out first
in the shared map and it's followed by the qoutfifo. As a result, we'd
generally be getting negative offsets here. We can't actually do a
partial sync anyways, so there was no consequence to getting this wrong.
Reviewed by: imp, mav
Differential Revision: https://reviews.freebsd.org/D44859
When in netmap (emulated) mode, wireguard interfaces prepend or strip a
dummy ethernet header when interfacing with netmap. The netmap
application thus sees unencrypted, de-encapsulated frames with a fixed
header.
In this mode, netmap hooks the if_input and if_transmit routines of the
ifnet. Packets from the host TX ring are handled by wg_if_input(),
which simply hands them to the netisr layer; packets which would
otherwise be tunneled are intercepted in wg_output() and placed in the
host RX ring.
The "physical" TX ring is processed by wg_transmit(), which behaves
identically to wg_output() when netmap is not enabled, and packets
appear in the "physical" RX ring by hooking wg_deliver_in().
Reviewed by: vmaffione
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Zenarmor
Differential Revision: https://reviews.freebsd.org/D43460
