aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/virtio
Commit message (Collapse)AuthorAgeFilesLines
* Stop redefining PAGE_SHIFT in virtio-mmioAndrew Turner2020-12-231-2/+0
| | | | | | | This is alreaady defined by each architecture as that is the only place we can know what the correct page shift should be. Sponsored by: Innovate UK
* virtio_mmio: Fix feature negotiation copy-paste issue in r361943Jessica Clarke2020-12-181-2/+2
| | | | | | | | | | | | | | This caused us to write to the low half of the feature word twice, once with the high bits and once with the low bits. Common legacy device implementations seem to be fairly lenient about being able to write to the feature bits multiple times, but Arm's models use a stricter implementation that will ignore the second write. This fixes using vtnet(4) on those models. Reported by: Jean-Philippe Brucker <jean-philippe@linaro.org> Pointy hat: jrtc27 Notes: svn path=/head/; revision=368761
* Make MAXPHYS tunable. Bump MAXPHYS to 1M.Konstantin Belousov2020-11-282-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys. Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value. Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work. Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav. Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225 Notes: svn path=/head/; revision=368124
* virtio: clean up empty lines in .c and .h filesMateusz Guzik2020-09-016-8/+0
| | | | Notes: svn path=/head/; revision=365091
* virtio: fix mips regression introduced by r357596Alfredo Dal'Ava Junior2020-07-281-23/+14
| | | | | | | | | | | | | | | | PowerPC support was fixed in r357596 by changing PCI bustag to BE as part of the solution, but this caused regression on mips. This change implements byte swapping of virtio PCI config area in the driver, leaving lower layer untouched. Submittnd by: Fernando Valle <fernando.valle@eldorado.org.br> Reported by: arichardson Reviewed by: alfredo, arichardson Sponsored by: Eldorado Research Institute (eldorado.org.br) Differential Revision: https://reviews.freebsd.org/D25416 Notes: svn path=/head/; revision=363646
* Only write to VIRTIO_MMIO_GUEST_PAGE_SIZE with virtio mmio version 1Andrew Turner2020-07-211-4/+8
| | | | | | | | | | This register is only defined for the legacy v1 interface so only write to it when interacting with a legacy device. Sponsored by: Innovate UK Notes: svn path=/head/; revision=363390
* Add VIRTIO_BLK_T_DISCARD support to the virtio-blk driverAllan Jude2020-07-162-31/+118
| | | | | | | | | | | | | | | | | | | 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 Reviewed by: jhb Tested by: freqlabs MFC after: 1 month Relnotes: yes Sponsored by: Klara Inc. Differential Revision: https://reviews.freebsd.org/D21708 Notes: svn path=/head/; revision=363255
* 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-084-8/+20
| | | | | | | | | | | | | | | 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
* virtio_mmio: Negotiate the upper half of the feature bits tooJessica Clarke2020-06-081-0/+11
| | | | | | | | | | | | | | | | | The feature bits are exposed as a 32-bit register with 2 banks, so we should negotiate both halves. Notably, VIRTIO_F_VERSION_1 is in the upper half, and will be used in an upcoming commit. The PCI bus driver also has this bug, but the legacy BAR layout did not include selector registers and is rather different from the modern layout, so it remains solely as legacy. Reviewed by: br, brooks (mentor), jhb (mentor) Approved by: br, brooks (mentor), jhb (mentor) Differential Revision: https://reviews.freebsd.org/D25131 Notes: svn path=/head/; revision=361943
* 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
* virtio_mmio: Add casts missing from r360722Jessica Clarke2020-05-071-3/+3
| | | | | | | | | | This fixes -Wshift-count-overflow warnings/errors on architectures using 32-bit physical addresses. Reported by: lwhsu Notes: svn path=/head/; revision=360789
* virtio: Support MMIO bus for all devicesJessica Clarke2020-05-064-0/+12
| | | | | | | | | | | | | The bus is independent of the device, so all devices can be attached to either a PCI bus or an MMIO bus. For example, QEMU's virtio-rng-device gives the MMIO variant of virtio-rng-pci, and is now detected. Reviewed by: andrew, br, brooks (mentor) Approved by: andrew, br, brooks (mentor) Differential Revision: https://reviews.freebsd.org/D24730 Notes: svn path=/head/; revision=360723
* virtio_mmio: Support non-transitional version 2 devicesJessica Clarke2020-05-062-22/+146
| | | | | | | | | | | | | | | | | | | The non-legacy virtio MMIO specification drops the use of PFNs and replaces them with physical addresses. Whilst many implementations are so-called transitional devices, also implementing the legacy specification, TinyEMU[1] does not. Device-specific configuration registers have also changed to being little-endian, and must be accessed using a single aligned access for registers up to 32 bits, and two 32-bit aligned accesses for 64-bit registers. [1] https://bellard.org/tinyemu/ Reviewed by: br, brooks (mentor) Approved by: br, brooks (mentor) Differential Revision: https://reviews.freebsd.org/D24681 Notes: svn path=/head/; revision=360722
* Remove FreeBSD 8 support from virtio.Warner Losh2020-03-011-5/+0
| | | | | | | | The sbuf API has evolved since 8, as have many others. The other API sweeps didn't make the changes conditional, so this is now noise. Notes: svn path=/head/; revision=358494
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)Pawel Biernacki2020-02-262-5/+7
| | | | | | | | | | | | | | | | | | | 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
* virtio: Pass the interrupt type in mmio modeKristof Provost2020-02-201-1/+1
| | | | | | | | | | | | | | When we register an interrupt handler we need to pass the intr_type along in bus_setup_intr(). The interrupt type matters because it is used to decide if we need to enter NET_EPOCH. That meant that vtmmio-based if_vtnet did not, which led to panics with INVARIANTS set. Sponsored by: Axiado Notes: svn path=/head/; revision=358178
* 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
* Ever since the block layer expanded its command syntax beyond justScott Long2020-02-071-0/+6
| | | | | | | | | | | BIO_READ and BIO_WRITE, we've handled this expanded syntax poorly in drivers when the driver doesn't support a particular command. Do a sweep and fix that. Reported by: imp Notes: svn path=/head/; revision=357647
* [virtio] Fix r/w to PCI configuration area on big endian platformsAlfredo Dal'Ava Junior2020-02-051-13/+36
| | | | | | | | | | | | | | | | | | | In legacy VirtIO drivers, the header must be PCI endianness (little) and the device-specific region is encoded in the native endian of the guest. This patch makes the access (read/write) to VirtIO header using the little endian order. Other read and write access are native endianness. This also sets the device's IO region as big endian if on big endian machine. PR: 205178 Submitted by: Andre Silva <afscoelho@gmail.com> Reported by: Kenneth Salerno <kennethsalerno@yahoo.com> Reviewed by: bryanv, bdragon, luporl, alfredo Approved by: jhibbits (mentor) Differential Revision: https://reviews.freebsd.org/D23401 Notes: svn path=/head/; revision=357596
* virtio_scsi: use max target ID plus one as the initiator IDAndriy Gapon2020-01-232-6/+1
| | | | | | | | | | | | | | | | | | 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(). Discussed with: bryanv MFC after: 2 weeks Sponsored by: Panzura Notes: svn path=/head/; revision=357040
* 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
* virtio_random(4): Drop no longer needed unload kludgeConrad Meyer2019-12-301-8/+0
| | | | | | | | | | After r356194, source deregistration no longer races with concurrent use. Reviewed by: bryanv, markm Differential Revision: https://reviews.freebsd.org/D22490 Notes: svn path=/head/; revision=356195
* Introduce vm_page_astate.Mark Johnston2019-12-101-1/+1
| | | | | | | | | | | | | | | | | This is a 32-bit structure embedded in each vm_page, consisting mostly of page queue state. The use of a structure makes it easy to store a snapshot of a page's queue state in a stack variable and use cmpset loops to update that state without requiring the page lock. This change merely adds the structure and updates references to atomic state fields. No functional change intended. Reviewed by: alc, jeff, kib Sponsored by: Netflix, Intel Differential Revision: https://reviews.freebsd.org/D22650 Notes: svn path=/head/; revision=355586
* Convert to if_foreach_llmaddr() KPI.Gleb Smirnoff2019-10-211-41/+38
| | | | Notes: svn path=/head/; revision=353802
* tap: add support for virtio-net offloadsVincenzo Maffione2019-10-181-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | This patch is part of an effort to make bhyve networking (in particular TCP) faster. The key strategy to enhance TCP throughput is to let the whole packet datapath work with TSO/LRO packets (up to 64KB each), so that the per-packet overhead is amortized over a large number of bytes. This capability is supported in the guest by means of the vtnet(4) driver, which is able to handle TSO/LRO packets leveraging the virtio-net header (see struct virtio_net_hdr and struct virtio_net_hdr_mrg_rxbuf). A bhyve VM exchanges packets with the host through a network backend, which can be vale(4) or if_tap(4). While vale(4) supports TSO/LRO packets, if_tap(4) does not. This patch extends if_tap(4) with the ability to understand the virtio-net header, so that a tapX interface can process TSO/LRO packets. A couple of ioctl commands have been added to configure and probe the virtio-net header. Once the virtio-net header is set, the tapX interface acquires all the IFCAP capabilities necessary for TSO/LRO. Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D21263 Notes: svn path=/head/; revision=353741
* Split out a more generic debugnet(4) from netdump(4)Conrad Meyer2019-10-171-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Debugnet is a simplistic and specialized panic- or debug-time reliable datagram transport. It can drive a single connection at a time and is currently unidirectional (debug/panic machine transmit to remote server only). It is mostly a verbatim code lift from netdump(4). Netdump(4) remains the only consumer (until the rest of this patch series lands). The INET-specific logic has been extracted somewhat more thoroughly than previously in netdump(4), into debugnet_inet.c. UDP-layer logic and up, as much as possible as is protocol-independent, remains in debugnet.c. The separation is not perfect and future improvement is welcome. Supporting INET6 is a long-term goal. Much of the diff is "gratuitous" renaming from 'netdump_' or 'nd_' to 'debugnet_' or 'dn_' -- sorry. I thought keeping the netdump name on the generic module would be more confusing than the refactoring. The only functional change here is the mbuf allocation / tracking. Instead of initiating solely on netdump-configured interface(s) at dumpon(8) configuration time, we watch for any debugnet-enabled NIC for link activation and query it for mbuf parameters at that time. If they exceed the existing high-water mark allocation, we re-allocate and track the new high-water mark. Otherwise, we leave the pre-panic mbuf allocation alone. In a future patch in this series, this will allow initiating netdump from panic ddb(4) without pre-panic configuration. No other functional change intended. Reviewed by: markj (earlier version) Some discussion with: emaste, jhb Objection from: marius Differential Revision: https://reviews.freebsd.org/D21421 Notes: svn path=/head/; revision=353685
* Revert r352406, which contained changes I didn't intend to commit.Mark Johnston2019-09-161-0/+2
| | | | Notes: svn path=/head/; revision=352407
* Fix a couple of nits in r352110.Mark Johnston2019-09-161-2/+0
| | | | | | | | | | | | | - Remove a dead variable from the amd64 pmap_extract_and_hold(). - Fix grammar in the vm_page_wire man page. Reported by: alc Reviewed by: alc, kib Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21639 Notes: svn path=/head/; revision=352406
* virtio: Fix running on machines with memory above 0xffffffffKristof Provost2019-07-262-2/+2
| | | | | | | | | | | | | | We want to allocate a contiguous memory block anywhere in memory, but expressed this as having to be between 0 and 0xffffffff. This limits us on 64-bit machines, and outright breaks on machines where memory is mapped above that address range. Allow the full address range to be used for this allocation. Sponsored by: Axiado Notes: svn path=/head/; revision=350364
* VirtIO SCSI: validate seg_max on attachEric van Gyzen2019-06-221-0/+23
| | | | | | | | | | | | | | | | Until r349278, 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 MFC after: 1 week Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20703 Notes: svn path=/head/; revision=349285
* virtio(4): Add PNP match metadata for virtio devicesConrad Meyer2019-06-047-42/+54
| | | | | | | | | | | | | | Register MODULE_PNP_INFO for virtio devices using the newbus PNP information provided by the previous commit. Matching can be quite simple; existing probe routines only matched on bus (implicit) and device_type. The same matching criteria are retained exactly, but is now also available to devmatch(8). Reviewed by: bryanv, markj; imp (earlier version) Differential Revision: https://reviews.freebsd.org/D20407 Notes: svn path=/head/; revision=348599
* virtio(4): Expose PNP metadata through newbusConrad Meyer2019-06-044-0/+36
| | | | | | | | | | | | | | | | | | | Expose the same fields and widths from both vtio buses, even though they don't quite line up; several virtio drivers can attach to both buses, and sharing a PNP info table for both seems more convenient. In practice, I doubt any virtio driver really needs to match on anything other than bus and device_type (eliminating the unused entries for vtmmio), and also in practice device_type is << 2^16 (so far, values range from 1 to 20). So it might be fine to only expose a 16-bit device_type for PNP purposes. On the other hand, I don't see much harm in overkill here. Reviewed by: bryanv, markj (earlier version) Differential Revision: https://reviews.freebsd.org/D20406 Notes: svn path=/head/; revision=348598
* virtio_random(4): Fix random(4) integrationConrad Meyer2019-06-041-26/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | random(4) masks unregistered entropy sources. Prior to this revision, virtio_random(4) did not correctly register a random_source and did not function as a source of entropy. Random source registration for loadable pure sources requires registering a poll callback, which is invoked periodically by random(4)'s harvestq kthread. The periodic poll makes virtio_random(4)'s periodic entropy collection redundant, so this revision removes the callout. The current random source API is somewhat limiting, so simply fail to attach any virtio_random devices if one is already registered as a source. This scenario is expected to be uncommon. While here, handle the possibility of short reads from the hypervisor random device gracefully / correctly. It is not clear why a hypervisor would return a short read or if it is allowed by spec, but we may as well handle it. Reviewed by: bryanv (earlier version), markm Security: yes (note: many other "pure" random sources remain broken) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20419 Notes: svn path=/head/; revision=348595
* random(4): Fix RANDOM_LOADABLE buildConrad Meyer2019-06-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. PR: 238223 Reported by: Eir Nym <eirnym AT gmail.com> Reviewed by: delphij, markm Approved by: secteam(delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20466 Notes: svn path=/head/; revision=348489
* virtio_random(4): Remove unneeded reference to deviceConrad Meyer2019-05-271-16/+11
| | | | | | | | The device_t always references the softc, so we can pass the device and obtain the softc instead of the other way around. Notes: svn path=/head/; revision=348295
* virtio_pci(4): Fix typo in read_ivar methodConrad Meyer2019-05-251-1/+1
| | | | | | | | | | | | | | | Prior to this revision, vtpci's BUS_READ_IVAR method on VIRTIO_IVAR_SUBVENDOR accidentally returned the PCI subdevice. The typo seems to have been introduced with the original commit adding VIRTIO_IVAR_{{SUB,}DEVICE,{SUB,}VENDOR} to virtio_pci. The commit log and code strongly suggest that the ivar was intended to return the subvendor rather than the subdevice; it was likely just a copy/paste mistake. Go ahead and rectify that. Notes: svn path=/head/; revision=348262
* Remove non-functional SCTP checksum offload support for virtio.Michael Tuexen2019-05-072-11/+2
| | | | | | | | | | | | | | | | | | | | | | 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. Reviewed by: bryanv@ MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D20147 Notes: svn path=/head/; revision=347233
* Fix SCSI sense data pass through.Alexander Motin2019-04-121-2/+1
| | | | | | | | MFC after: 1 week Sponsored by: iXsystems, Inc. Notes: svn path=/head/; revision=346161
* vtnet: fix typo in vtnet_free_taskqueuesVincenzo Maffione2019-01-291-1/+1
| | | | | | | | | | | | Because of a typo, the code was mistakenly resetting the vtnrx_vq pointer rather than vtntx_tq. Reviewed by: bryanv MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D19015 Notes: svn path=/head/; revision=343552
* vtnet: fix netmap supportVincenzo Maffione2018-11-142-34/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | netmap(4) support for vtnet(4) was incomplete and had multiple bugs. This commit fixes those bugs to bring netmap on vtnet in a functional state. Changelist: - handle errors returned by virtqueue_enqueue() properly (they were previously ignored) - make sure netmap XOR rest of the kernel access each virtqueue. - compute the number of netmap slots for TX and RX separately, according to whether indirect descriptors are used or not for a given virtqueue. - make sure sglist are freed according to their type (mbufs or netmap buffers) - add support for mulitiqueue and netmap host (aka sw) rings. - intercept VQ interrupts directly instead of intercepting them in txq_eof and rxq_eof. This simplifies the code and makes it easier to make sure taskqueues are not running for a VQ while it is in netmap mode. - implement vntet_netmap_config() to cope with changes in the number of queues. Reviewed by: bryanv Approved by: gnn (mentor) MFC after: 3 days Sponsored by: Sunny Valley Networks Differential Revision: https://reviews.freebsd.org/D17916 Notes: svn path=/head/; revision=340436
* Split out the virtio mmio FDT attachment and add an ACPI attachment.Andrew Turner2018-10-214-97/+259
| | | | | | | | | | This allows the memory mapped I/O virtio driver to attach when we boot with ACPI tables, for example in some cases with QEMU emulating arm64. MFC after: 1 month Notes: svn path=/head/; revision=339540
generated by cgit v1.3 (git 2.53.0) at 2026-04-09 07:11:15 +0000