aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/virtio/network
Commit message (Collapse)AuthorAgeFilesLines
...
* vtnet: don't leak pfil(9) data on detachGleb Smirnoff2022-01-051-0/+5
| | | | | PR: 260667 Submitted by: <ghuckriede blackberry.com>
* virtio: plug some of set-but-not-used varsMateusz Guzik2021-12-141-0/+6
| | | | Sponsored by: Rubicon Communications, LLC ("Netgate")
* vtnet: plug set-but-not-used varsMateusz Guzik2021-12-141-5/+5
| | | | Sponsored by: Rubicon Communications, LLC ("Netgate")
* virtio: Add KMSAN hooks for network and block devicesMark Johnston2021-08-111-1/+4
| | | | | | This ensures that host-written data is marked as initialized. Sponsored by: The FreeBSD Foundation
* virtio: enable VTNET_LEGACY_TX when ALTQ is enabled.Luiz Otavio O Souza2021-07-291-0/+4
| | | | | | | | | 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")
* Fix vtnet TCP lro panicAlexander V. Chernikov2021-04-191-1/+2
| | | | | Differential Revision: https://reviews.freebsd.org/D29900 Reviewed by: hps, kp
* vtnet: fix TSO for TCP/IPv6Michael Tuexen2021-03-181-4/+4
| | | | | | | | | | | | | | | | | | The decision whether a TCP packet is sent over IPv4 or IPv6 was based on ethertype, which works correctly. In D27926 the criteria was changed to checking if the CSUM_IP_TSO flag is set in the csum-flags and then considering it to be TCP/IPv4. However, the TCP stack sets the flag to CSUM_TSO for IPv4 and IPv6, where CSUM_TSO is defined as CSUM_IP_TSO|CSUM_IP6_TSO. Therefore TCP/IPv6 packets gets mis-classified as TCP/IPv4, which breaks TSO for TCP/IPv6. This patch bases the check again on the ethertype. This fix will be MFC instantly as discussed with re(gjb). MFC after: instantly PR: 254366 Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D29331
* if_vtnet: Fix pointer-sign and used parameter warningsAlex Richardson2021-02-222-24/+24
| | | | | Reviewed By: grehan Differential Revision: https://reviews.freebsd.org/D28726
* virtio: Reduce boilerplate for device driver module definitionsJessica Clarke2021-01-211-6/+2
| | | | | | | | | | | Rather than have every device register itself for both virtio_pci and virtio_mmio, provide a VIRTIO_DRIVER_MODULE wrapper to declare both, merge VIRTIO_SIMPLE_PNPTABLE with VIRTIO_SIMPLE_PNPINFO and make the latter register for both buses. This also has the benefit of abstracting away the available transports and their names. Reviewed by: bryanv Differential Revision: https://reviews.freebsd.org/D28073
* virtio: Handle possible failure of virtio_finalize_features()Bryan Venteicher2021-01-191-8/+17
| | | | | | | | Try to standardize how drivers negotiate feature and the function names Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27930
* if_vtnet: Add counter for received host LROBryan Venteicher2021-01-192-0/+4
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27928
* if_vtnet: Misc Tx path cleanupBryan Venteicher2021-01-192-29/+41
| | | | | | | | | - Add and fix a few error path counters - Improve sysctl descriptions - Use flags consistently to determine IPv4 vs IPv6 Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27926
* if_vtnet: Set lro_nsegs for host LRO packetsBryan Venteicher2021-01-191-0/+10
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27933
* if_vtnet: Resort softc fieldsBryan Venteicher2021-01-191-7/+7
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27925
* if_vtnet: Remove unnecessary TUNABLE_INTs because of CTLFLAG_RDTUNBryan Venteicher2021-01-191-15/+9
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27923
* if_vtnet: Schedule Rx task if pending items when enabling interruptBryan Venteicher2021-01-191-4/+10
| | | | | | | | | | | | | Prior to V1, the driver would enable interrupts and then notify the host that DRIVER_OK. Since for V1, DRIVER_OK needs to be set before notifying the virtqueues, there may be items in the queues waiting to be processed by the time interrupts are enabled. This fixes a bug where the Rx queue would appear stuck, only being usable after an interface down/up cycle. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27922
* if_vtnet: Disable F_MTU feature if MTU is invalidBryan Venteicher2021-01-192-0/+15
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27931
* if_vtnet: Limit allocations of unused virtqueuesBryan Venteicher2021-01-191-13/+27
| | | | | | | | | For multiqueue, we may use fewer than the provided maximum number of queues. Try to limit allocations of the unused queues: no interrupts, no indirect descriptors, and no taskqueues. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27921
* if_vtnet: Rework 4be723f63 max multiqueue pairs checkBryan Venteicher2021-01-192-18/+32
| | | | | | | | Verify the max_virtqueue_pairs is within the range allowed by the spec. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27920
* if_vtnet: Add support for software LROBryan Venteicher2021-01-192-24/+122
| | | | | | | | | | | | | This useful when running on hosts that support checksum offloading but not the GUEST_TSO (LRO) feature. Or potentially, some GRO-like support when doing forwarding. Only enable SW LRO when the host LRO is not available since both tends to be harmful, and difficult to enable/disable selectively with only a single IFCAP_LRO flag. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27919
* if_vtnet: Set the interface max TSO valuesBryan Venteicher2021-01-191-1/+16
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27917
* if_vtnet: Add support for CTRL_GUEST_OFFLOADS featureBryan Venteicher2021-01-192-31/+127
| | | | | | | | | | | | | | This allows the Rx checksum and LRO to be modified without a full reinit of the device. Remove IFCAP_RXCSUM_IPV6 from the interface capabilities since in VirtIO Rx checksums are just enabled or disabled for all protocols. Properly update IFCAP_LRO if LRO is becomes disabled when Rx checksums are disabled. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27916
* if_vtnet: Move ioctl handlers into separate functionsBryan Venteicher2021-01-191-62/+106
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27914 https://reviews.freebsd.org/D27915
* if_vtnet: Cleanup the reinit processBryan Venteicher2021-01-192-46/+46
| | | | | | | | In modern VirtIO, the virtqueues cannot be notified before setting DRIVER_OK status. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27932
* if_vtnet: Cleanup the interface setup methodsBryan Venteicher2021-01-191-38/+21
| | | | | | | | Defer the ether_ifattach until the interface capabilities are configured Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27913
* if_vtnet: Only set IFCAP_JUMBO_MTU when jumbo MTU is supportedBryan Venteicher2021-01-191-4/+7
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27912
* if_vtnet: Move the Tx interrupt threshold into the Txq structureBryan Venteicher2021-01-192-36/+33
| | | | | Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27911
* if_vtnet: Defer updating generated MAC address until attachedBryan Venteicher2021-01-191-23/+37
| | | | | | | | | | | | This improves spec compliance because the driver is not suppose to notify the device prior to setting the DRIVER_OK status, which could happen with the VIRTIO_NET_F_CTRL_MAC_ADDR. The VIRTIO_NET_F_MAC feature should always be negotiated so would be a rare situation. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27910
* if_vtnet: Remove at attach PROMISC handlingBryan Venteicher2021-01-191-25/+0
| | | | | | | | | This may have been required in an early, early, early version of the specification but I cannot find any reference to it, and a promiscuous default seems very odd so remove this code. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27909
* if_vtnet: Support VIRTIO_NET_F_SPEED_DUPLEXBryan Venteicher2021-01-192-23/+39
| | | | | | | | | | | | This features lets the guest driver know the speed and duplex of the "link". Instead of trying to support many media types based on the possible/likely speeds/duplexes, only use the speed to set the interface baudrate. Cleanup ifmedia code to match other drivers. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27908
* if_vtnet: Support VIRTIO_NET_F_MTUBryan Venteicher2021-01-192-5/+12
| | | | | | | | | | This feature lets the guest driver know the maximum MTU size supported by the host device. If set, use this to limit the acceptable MTUs, and improve how the receive mbuf cluster size then is selected. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27907
* if_vtnet: Rx path cleanupBryan Venteicher2021-01-192-311/+296
| | | | | | | | | | | | | | | | | | - Fix the NEEDS_CSUM and DATA_VALID checksum flags. The NEEDS_CSUM checksum is incomplete (partial) so offer a fallback for the driver to calculate the checksum. Simplify DATA_VALID because we know the host has validated the checksum. - Default 4K mbuf clusters for mergeable buffers. May need to scale this down to 2K clusters in certain configurations such many queue pairs, big queues (like 4096 in GCP), and low memory. - Use the MTU when calculated the receive mbuf cluster size when not doing TSO/LRO. This will need more adjustment once the MTU feature is supported. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27906
* if_vtnet: Add initial modern (V1) supportBryan Venteicher2021-01-193-352/+421
| | | | | | | | | | | Very basic support to get packets flowing on modern QEMU but still several conformance issues remain that will be addressed in later commits. First of many passes at cleaning up various accumulated cruft Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27904
* Revert: virtio: Support non-legacy network device and queueBryan Venteicher2021-01-192-21/+10
| | | | | | | | | | | | | | | | | | | | | And subsequent fix 576b099a. By adding the mergable header to the vtnet_rx_header structure, the size was increased by 2 bytes, breaking the alignment of this structure as described the in preceding comments. Furthermore, the mergable header does not belong the structure. With the mergable feature, the header is placed in line with the data, so there is no need for a separate segment, and misleading to follow the mergable header with any padding. The V1 header is effectively identical to mergable header, and the driver has long supported the mergable feature. Revert this so the later changes that add V1 support can show how V1 is derived from the existing mergable buffers support, and to facilitate a later MFC. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27855
* netmap: vtnet: enable/disable krings on any interface reinitVincenzo Maffione2021-01-101-0/+10
| | | | | | | See 3d65fd97e85ab807f3b for a detailed explanation. PR: 252453 MFC after: 1 week
* virtio: clean up empty lines in .c and .h filesMateusz Guzik2020-09-011-1/+0
| | | | Notes: svn path=/head/; revision=365091
* if_vtnet: let vtnet_rx_vq_intr() and vtnet_rxq_tq_intr() share codeVincenzo Maffione2020-06-151-42/+14
| | | | | | | | | | | | | | 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 MFC after: 2 weeks Notes: svn path=/head/; revision=362204
* vtnet: Fix regression introduced in r361944Jessica Clarke2020-06-141-2/+3
| | | | | | | | | | | | | | | For legacy devices that don't support MrgRxBuf (such as bhyve pre-r358180), r361944 failed to update the receive handler to account for the additional padding introduced by the unused num_buffers field that is now always present in struct vtnet_rx_header. Thus, calculate the padding dynamically based on vtnet_hdr_size. PR: 247242 Reported by: thj Tested by: thj Notes: svn path=/head/; revision=362186
* netmap: vtnet: fix races in vtnet_netmap_reg()Vincenzo Maffione2020-06-142-8/+29
| | | | | | | | | | | | | | | | | | | | | 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. MFC after: 1 week Notes: svn path=/head/; revision=362183
* netmap: introduce netmap_kring_on()Vincenzo Maffione2020-06-111-8/+8
| | | | | | | | | | | | 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(). MFC after: 1 week Notes: svn path=/head/; revision=362076
* virtio: Support non-legacy network device and queueJessica Clarke2020-06-082-8/+18
| | | | | | | | | | | | | | | The non-legacy interface always defines num_buffers in the header, regardless of whether VIRTIO_NET_F_MRG_RXBUF, just leaving it unused. We also need to ensure our virtqueue doesn't filter out VIRTIO_F_VERSION_1 during negotiation, as it supports non-legacy transports just fine. This fixes network packet transmission on TinyEMU. Reviewed by: br, brooks (mentor), jhb (mentor) Approved by: br, brooks (mentor), jhb (mentor) Differential Revision: https://reviews.freebsd.org/D25132 Notes: svn path=/head/; revision=361944
* netmap: vtnet: add vtnrx_nm_refill index to receive queuesVincenzo Maffione2020-06-031-0/+1
| | | | | | | | | | | | | | | 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. MFC after: 1 week Notes: svn path=/head/; revision=361758
* netmap: vtnet: call netmap_rx_irq() under VQ lockVincenzo Maffione2020-06-031-4/+14
| | | | | | | | | | | | | | | | | | | 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. MFC after: 1 week Notes: svn path=/head/; revision=361745
* netmap: vtnet: honor NM_IRQ_RESCHEDVincenzo Maffione2020-06-031-1/+22
| | | | | | | | | | | | 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. MFC after: 1 week Notes: svn path=/head/; revision=361744
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)Pawel Biernacki2020-02-261-3/+4
| | | | | | | | | | | | | | | | | | | r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718 Notes: svn path=/head/; revision=358333
* Although most of the NIC drivers are epoch ready, due to peer pressureGleb Smirnoff2020-02-241-1/+2
| | | | | | | | | | | | | | | | | | | switch over to opt-in instead of opt-out for epoch. Instead of IFF_NEEDSEPOCH, provide IFF_KNOWSEPOCH. If driver marks itself with IFF_KNOWSEPOCH, then ether_input() would not enter epoch when processing its packets. Now this will create recursive entrance in epoch in >90% network drivers, but will guarantee safeness of the transition. Mark several tested drivers as IFF_KNOWSEPOCH. Reviewed by: hselasky, jeff, bz, gallatin Differential Revision: https://reviews.freebsd.org/D23674 Notes: svn path=/head/; revision=358301
* Use NET_TASK_INIT() and NET_GROUPTASK_INIT() for drivers that processGleb Smirnoff2020-02-111-1/+1
| | | | | | | | | | incoming packets in taskqueue context. Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D23518 Notes: svn path=/head/; revision=357772
* Pacify gcc.Gleb Smirnoff2020-01-111-1/+1
| | | | | | | Reported by: rlibby Notes: svn path=/head/; revision=356639
* Add pfil(9) hook to vtnet(4).Gleb Smirnoff2020-01-102-1/+54
| | | | | | | | | | | | | | The patch could be simplier, using only the second chunk to vtnet_rxq_eof(), that passes full mbufs to pfil(9). Packet filter would m_free() them in case of returning PFIL_DROPPED. However, we pretend to be a hardware driver, so we first try to pass a memory buffer via PFIL_MEMPTR feature. This is mostly done for debugging purposes, so that one can experiment in bhyve with packet filters utilizing same features as a true driver. Notes: svn path=/head/; revision=356613
* vtnet: Pre-allocate debugnet data immediatelyKristof Provost2020-01-081-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't wait until the vtnet_debugnet_init() call happens, because at that point we might already have allocated something from vtnet_tx_header_zone. Some systems showed this panic: vtnet0: link state changed to UP panic: keg vtnet_tx_hdr initialization after use. cpuid = 5 time = 1578427700 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe004db427f0 vpanic() at vpanic+0x17e/frame 0xfffffe004db42850 panic() at panic+0x43/frame 0xfffffe004db428b0 uma_zone_reserve() at uma_zone_reserve+0xf6/frame 0xfffffe004db428f0 vtnet_debugnet_init() at vtnet_debugnet_init+0x77/frame 0xfffffe004db42930 debugnet_any_ifnet_update() at debugnet_any_ifnet_update+0x42/frame 0xfffffe004db42980 do_link_state_change() at do_link_state_change+0x1b3/frame 0xfffffe004db429d0 taskqueue_run_locked() at taskqueue_run_locked+0x178/frame 0xfffffe004db42a30 taskqueue_run() at taskqueue_run+0x4d/frame 0xfffffe004db42a50 ithread_loop() at ithread_loop+0x1d6/frame 0xfffffe004db42ab0 fork_exit() at fork_exit+0x80/frame 0xfffffe004db42af0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004db42af0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 12 tid 100011 ] Stopped at kdb_enter+0x37: movq $0,0x1084eb6(%rip) db> Reviewed by: cem, markj Differential Revision: https://reviews.freebsd.org/D23073 Notes: svn path=/head/; revision=356484
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-27 00:10:20 +0000