<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/dev/virtio, branch releng/12.2</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>MFC r360229, r363255</title>
<updated>2020-09-13T23:51:07+00:00</updated>
<author>
<name>Allan Jude</name>
<email>allanjude@FreeBSD.org</email>
</author>
<published>2020-09-13T23:51:07+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4e5ba9e475fb3e006664144bd752d39e4dd0c2bb'/>
<id>4e5ba9e475fb3e006664144bd752d39e4dd0c2bb</id>
<content type='text'>
MFS r365614

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

Approved by:	re (gjb)
Relnotes:	yes
Sponsored by:	Klara Inc.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MFS r365614

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

Approved by:	re (gjb)
Relnotes:	yes
Sponsored by:	Klara Inc.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r362204</title>
<updated>2020-07-01T19:42:23+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-07-01T19:42:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9b8f0814882923c3cbbb39ad852bcd5460d1fa4a'/>
<id>9b8f0814882923c3cbbb39ad852bcd5460d1fa4a</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r362183</title>
<updated>2020-06-23T20:41:10+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-06-23T20:41:10+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=e2573c8c1836ac4c91d5fd042c69e0d4932a2ea4'/>
<id>e2573c8c1836ac4c91d5fd042c69e0d4932a2ea4</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r362076</title>
<updated>2020-06-18T10:03:17+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-06-18T10:03:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=eb49c2778b3b0cfc38eb5659ec94a48bd5d251c9'/>
<id>eb49c2778b3b0cfc38eb5659ec94a48bd5d251c9</id>
<content type='text'>
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().
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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().
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r361758</title>
<updated>2020-06-10T20:04:20+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-06-10T20:04:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=0dd06b856e0076af19d1a828f6751342b75c8e49'/>
<id>0dd06b856e0076af19d1a828f6751342b75c8e49</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r361745</title>
<updated>2020-06-10T20:02:38+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-06-10T20:02:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=c3c61399d66e6ba3b6c0dba7d30be7f87528c29c'/>
<id>c3c61399d66e6ba3b6c0dba7d30be7f87528c29c</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r361744</title>
<updated>2020-06-10T19:59:11+00:00</updated>
<author>
<name>Vincenzo Maffione</name>
<email>vmaffione@FreeBSD.org</email>
</author>
<published>2020-06-10T19:59:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4e13200941b362f02f4331a47e081c9596fcf74c'/>
<id>4e13200941b362f02f4331a47e081c9596fcf74c</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r357040: virtio_scsi: use max target ID plus one as the initiator ID</title>
<updated>2020-02-27T14:52:55+00:00</updated>
<author>
<name>Andriy Gapon</name>
<email>avg@FreeBSD.org</email>
</author>
<published>2020-02-27T14:52:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4f6e8eeebe3020a3ec366e8f86c79a1e7b650799'/>
<id>4f6e8eeebe3020a3ec366e8f86c79a1e7b650799</id>
<content type='text'>
This bus does not really have a concept of the initiator ID, so use
a guaranteed dummy one that won't conflict with any real target.

This change fixes a problem with virtio_scsi on GCE where disks get
sequential target IDs starting from one.  If there are seven or more
disks, then a disk with the target ID of seven would not be discovered
by FreeBSD as that ID was reserved as the initiator ID -- see
scsi_scan_bus().

Sponsored by:	Panzura
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This bus does not really have a concept of the initiator ID, so use
a guaranteed dummy one that won't conflict with any real target.

This change fixes a problem with virtio_scsi on GCE where disks get
sequential target IDs starting from one.  If there are seven or more
disks, then a disk with the target ID of seven would not be discovered
by FreeBSD as that ID was reserved as the initiator ID -- see
scsi_scan_bus().

Sponsored by:	Panzura
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r349285</title>
<updated>2019-07-03T19:52:24+00:00</updated>
<author>
<name>Eric van Gyzen</name>
<email>vangyzen@FreeBSD.org</email>
</author>
<published>2019-07-03T19:52:24+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=7b4d80f6e3f018cd80228fbd98e029aa4a722ab0'/>
<id>7b4d80f6e3f018cd80228fbd98e029aa4a722ab0</id>
<content type='text'>
VirtIO SCSI:  validate seg_max on attach

Until head r349278 (stable/12 r349690), bhyve presented a seg_max
to the guest that was too large.  Detect this case and clamp it to
the virtqueue size.  Otherwise, we would fail the "too many segments
to enqueue" assertion in virtqueue_enqueue().

I hit this by running a guest with a MAXPHYS of 256 KB.

Reviewed by:	bryanv cem
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D20703
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
VirtIO SCSI:  validate seg_max on attach

Until head r349278 (stable/12 r349690), bhyve presented a seg_max
to the guest that was too large.  Detect this case and clamp it to
the virtqueue size.  Otherwise, we would fail the "too many segments
to enqueue" assertion in virtqueue_enqueue().

I hit this by running a guest with a MAXPHYS of 256 KB.

Reviewed by:	bryanv cem
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D20703
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r347233:</title>
<updated>2019-05-17T08:19:43+00:00</updated>
<author>
<name>Michael Tuexen</name>
<email>tuexen@FreeBSD.org</email>
</author>
<published>2019-05-17T08:19:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=1218c570f80c9eeb896478df74bf6401c752aa80'/>
<id>1218c570f80c9eeb896478df74bf6401c752aa80</id>
<content type='text'>
Remove non-functional SCTP checksum offload support for virtio.

Checksum offloading for SCTP is not currently specified for virtio.
If the hypervisor announces checksum offloading support, it means TCP
and UDP checksum offload. If an SCTP packet is sent and the host announced
checksum offload support, the hypervisor inserts the IP checksum (16-bit)
at the correct offset, but this is not the right checksum, which is a CRC32c.
This results in all outgoing packets having the wrong checksum and therefore
breaking SCTP based communications.

This patch removes SCTP checksum offloading support from the virtio
network interface.

Thanks to Felix Weinrank for making me aware of the issue.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove non-functional SCTP checksum offload support for virtio.

Checksum offloading for SCTP is not currently specified for virtio.
If the hypervisor announces checksum offloading support, it means TCP
and UDP checksum offload. If an SCTP packet is sent and the host announced
checksum offload support, the hypervisor inserts the IP checksum (16-bit)
at the correct offset, but this is not the right checksum, which is a CRC32c.
This results in all outgoing packets having the wrong checksum and therefore
breaking SCTP based communications.

This patch removes SCTP checksum offloading support from the virtio
network interface.

Thanks to Felix Weinrank for making me aware of the issue.
</pre>
</div>
</content>
</entry>
</feed>
