I introduced an obvious compiler error in r346282, so this change fixes
that.

Unfortunately, RANDOM_LOADABLE isn't covered by our existing tinderbox, and
it seems like there were existing latent linking problems.  I believe these
were introduced on accident in r338324 during reduction of the boolean
expression(s) adjacent to randomdev.c and hash.c.  It seems the
RANDOM_LOADABLE build breakage has gone unnoticed for nine months.

This change correctly annotates randomdev.c and hash.c with !random_loadable
to match the pre-r338324 logic; and additionally updates the HWRNG drivers
in MD 'files.*', which depend on random_device symbols, with
!random_loadable (it is invalid for the kernel to depend on symbols from a
module).

(The expression for both randomdev.c and hash.c was the same, prior to
r338324: "optional random random_yarrow | random !random_yarrow
!random_loadable".  I.e., "random && (yarrow || !loadable)."  When Yarrow
was removed ("yarrow := False"), the expression was incorrectly reduced to
"optional random" when it should have retained "random && !loadable".)

Additionally, I discovered that virtio_random was missing a MODULE_DEPEND on
random_device, which breaks kld load/link of the driver on RANDOM_LOADABLE
kernels.  Address that issue as well.

(cherry picked from commit 5ca5dfe938c1e4c741dc4c7bd83c738714456978)

ALTQ only works on network drivers which use if_start (rather than
if_transmit). vtnet uses if_start if built with VTNET_LEGACY_TX. Default
to that the kernel is built with ALTQ enabled, to reduce user surprise.

MFC after:	1 week
Sponsored by:	Rubicon Communications, LLC ("Netgate")

(cherry picked from commit 5afe81a7b23afd27289ca40e04a6a764134d6273)

Similarly to what done for iflib in 1d238b07d5d4d9660ae0e,
this patch prevents access to the krings during the interface
reset triggered by netmap_register().

MFC after:	1 week

(cherry picked from commit 9ac59d42c0b4b6cd9c36a5dace7f49753c2e175a)

netmap: vtnet: enable/disable krings on any interface reinit

See 3d65fd97e85ab807f3b for a detailed explanation.

PR:             252453
MFC after:      1 week

(cherry picked from commit bb714db6d39583a9fbf5d11849c5e2365e7c0d80)

netmap: vtnet: fix RX initialization after netmap_reset()

At device reset, we must not publish those netmap receive buffers
that are owned by userspace (nm_kr_rxspace).

MFC after:	1 week

(cherry picked from commit 3005e10ddbfbec3ecf46a080607bb0d85986eee5)

r360229:
Add VIRTIO_BLK_T_DISCARD (TRIM) support to the bhyve virtio-blk backend

This will advertise support for TRIM to the guest virtio-blk driver and
perform the DIOCGDELETE ioctl on the backing storage if it supports it.

Thanks to Jason King and others at Joyent and illumos for expanding on
my original patch, adding improvements including better error handling
and making sure to following the virtio spec.

r363255:
Add VIRTIO_BLK_T_DISCARD support to the virtio-blk driver

If the hypervisor advertises support for the DISCARD command then the
guest can perform TRIM commands, freeing space on the backing store.

If VIRTIO_BLK_F_DISCARD is enabled, advertise DISKFLAG_CANDELETE

Tested with FreeBSD guests on bhyve and KVM

Relnotes:	yes
Sponsored by:	Klara Inc.

if_vtnet: let vtnet_rx_vq_intr() and vtnet_rxq_tq_intr() share code

Since the two functions are similar, introduce a common function
(vtnet_rx_vq_process()) to share common code.
This also improves locking, by ensuring vrxs_rescheduled is accessed
under the RXQ lock, and taskqueue_enqueue() is not called under the
lock (therefore avoiding a spurious duplicate lock warning).

Reported by:    jrtc27

netmap: vtnet: fix races in vtnet_netmap_reg()

The nm_register callback needs to call nm_set_native_flags()
or nm_clear_native_flags() once the device has been stopped.
However, in the current implementation this is not true,
as the device is stopped by vtnet_init_locked(). This causes
race conditions where the driver crashes as soon as it
dequeues netmap buffers assuming they are mbufs (or the other
way around).
To fix the issue, we extend vtnet_init_locked() with a second
argument that, if not zero, will set/clear the netmap flags.
This results in a huge simplification of the nm_register
callback itself.
Also, use netmap_reset() to check if a ring is going to be
re-initialized in netmap mode.

netmap: introduce netmap_kring_on()

This function returns NULL if the ring identified by
queue id and direction is in netmap mode. Otherwise
return the corresponding kring.
Use this function to replace vtnet_netmap_queue_on().

netmap: vtnet: add vtnrx_nm_refill index to receive queues

The new index tracks the next netmap slot that is going
to be enqueued into the virtqueue. The index is necessary
to prevent the receive VQ and the netmap rx ring from going
out of sync, considering that we never enqueue N slots, but
at most N-1. This change fixes a bug that causes the VQ
and the netmap ring to go out of sync after N-1 packets
have been received.

netmap: vtnet: call netmap_rx_irq() under VQ lock

The netmap_rx_irq() function normally wakes up user-space threads
waiting for more packets. In this case, it is not necessary to
call it under the driver queue lock. However, if the interface is
attached to a VALE switch, netmap_rx_irq() ends up calling rxsync
on the interface (see netmap_bwrap_intr_notify()). Although
concurrent rxsyncs are serialized through the kring lock
(see nm_kr_tryget()), the lock acquire operation is not blocking.
As a result, it may happen that netmap_rx_irq() is called on
an RX ring while another instance is running, causing the
second call to fail, and received packets stall in the receive VQ.
We fix this issue by calling netmap_irx_irq() under the VQ lock.

netmap: vtnet: honor NM_IRQ_RESCHED

The netmap_rx_irq() function may return NM_IRQ_RESCHED to inform the
driver that more work is pending, and that netmap expects netmap_rx_irq()
to be called again as soon as possible.
This change implements this behaviour in the vtnet driver.