src/sys/modules/virtio, branch releng/15.0 FreeBSD source tree Add an implementation of the 9P filesystem 2024-06-19T12:12:04+00:00 Doug Rabson dfr@FreeBSD.org 2022-12-06T13:07:46+00:00 e97ad33a89a78f55280b0485b3249ee9b907a718 This is derived from swills@ fork of the Juniper virtfs with many changes by me including bug fixes, style improvements, clearer layering and more consistent logging. The filesystem is renamed to p9fs to better reflect its function and to prevent possible future confusion with virtio-fs. Several updates and fixes from Juniper have been integrated into this version by Val Packett and these contributions along with the original Juniper authors are credited below. To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The bhyve virtio-9p device allows access from the guest to files on the host by mapping a 'sharename' to a host path. It is possible to use p9fs as a root filesystem by adding this to /boot/loader.conf: vfs.root.mountfrom="p9fs:sharename" for non-root filesystems add something like this to /etc/fstab: sharename /mnt p9fs rw 0 0 In both examples, substitute the share name used on the bhyve command line. The 9P filesystem protocol relies on stateful file opens which map protocol-level FIDs to host file descriptors. The FreeBSD vnode interface doesn't really support this and we use heuristics to guess the right FID to use for file operations. This can be confused by privilege lowering and does not guarantee that the FID created for a given file open is always used for file operations, even if the calling process is using the file descriptor from the original open call. Improving this would involve changes to the vnode interface which is out-of-scope for this import. Differential Revision: https://reviews.freebsd.org/D41844 Reviewed by: kib, emaste, dch MFC after: 3 months Co-authored-by: Val Packett <val@packett.cool> Co-authored-by: Ka Ho Ng <kahon@juniper.net> Co-authored-by: joyu <joyul@juniper.net> Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net> 
This is derived from swills@ fork of the Juniper virtfs with many
changes by me including bug fixes, style improvements, clearer layering
and more consistent logging. The filesystem is renamed to p9fs to better
reflect its function and to prevent possible future confusion with
virtio-fs.

Several updates and fixes from Juniper have been integrated into this
version by Val Packett and these contributions along with the original
Juniper authors are credited below.

To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
bhyve virtio-9p device allows access from the guest to files on the host
by mapping a 'sharename' to a host path. It is possible to use p9fs as a
root filesystem by adding this to /boot/loader.conf:

	vfs.root.mountfrom="p9fs:sharename"

for non-root filesystems add something like this to /etc/fstab:

	sharename /mnt p9fs rw 0 0

In both examples, substitute the share name used on the bhyve command
line.

The 9P filesystem protocol relies on stateful file opens which map
protocol-level FIDs to host file descriptors. The FreeBSD vnode
interface doesn't really support this and we use heuristics to guess the
right FID to use for file operations.  This can be confused by privilege
lowering and does not guarantee that the FID created for a given file
open is always used for file operations, even if the calling process is
using the file descriptor from the original open call. Improving this
would involve changes to the vnode interface which is out-of-scope for
this import.

Differential Revision: https://reviews.freebsd.org/D41844
Reviewed by: kib, emaste, dch
MFC after: 3 months
Co-authored-by: Val Packett <val@packett.cool>
Co-authored-by: Ka Ho Ng <kahon@juniper.net>
Co-authored-by: joyu <joyul@juniper.net>
Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net>
sys: Remove $FreeBSD$: one-line sh pattern 2023-08-16T17:54:58+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:58+00:00 031beb4e239bfce798af17f5fe8dba8bcaf13d99 Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ 
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
Fix some modules to export more used symbols 2021-11-18T13:56:23+00:00 Konstantin Belousov kib@FreeBSD.org 2021-11-07T08:42:24+00:00 5bb3134a8c21cb87b30e135ef168483f0333dabb and remove non-present symbols that are now reported by kmod_syms.awk. Reviewed by: emaste Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32878 
and remove non-present symbols that are now reported by kmod_syms.awk.

Reviewed by:	emaste
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D32878
virtio: Add VirtIO PCI modern (V1) support 2021-01-19T04:55:23+00:00 Bryan Venteicher bryanv@FreeBSD.org 2021-01-19T04:55:23+00:00 9da9560c4dd3556519cd391a04f0db157dc3c295 Use the existing legacy PCI driver as the basis for shared code between the legacy and modern PCI drivers. The existing virtio_pci kernel module will contain both the legacy and modern drivers. Changes to the virtqueue and each device driver (network, block, etc) for V1 support come in later commits. Update the MMIO driver to reflect the VirtIO bus method changes, but the modern compliance can be improved on later. Note that the modern PCI driver requires bus_map_resource() to be implemented, which is not the case on all archs. The hw.virtio.pci.transitional tunable default value is zero so transitional devices will continue to be driven via the legacy driver. Reviewed by: grehan (mentor) Differential Revision: https://reviews.freebsd.org/D27856 
Use the existing legacy PCI driver as the basis for shared code
between the legacy and modern PCI drivers. The existing virtio_pci
kernel module will contain both the legacy and modern drivers.

Changes to the virtqueue and each device driver (network, block, etc)
for V1 support come in later commits.

Update the MMIO driver to reflect the VirtIO bus method changes, but
the modern compliance can be improved on later.

Note that the modern PCI driver requires bus_map_resource() to be
implemented, which is not the case on all archs.

The hw.virtio.pci.transitional tunable default value is zero so
transitional devices will continue to be driven via the legacy
driver.

Reviewed by: grehan (mentor)
Differential Revision: https://reviews.freebsd.org/D27856
sys/modules: normalize .CURDIR-relative paths to SRCTOP 2017-03-04T10:10:17+00:00 Enji Cooper ngie@FreeBSD.org 2017-03-04T10:10:17+00:00 193d9e768ba63fcfb187cfd17f461f7d41345048 This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon 
This simplifies make output/logic

Tested with:	`cd sys/modules; make ALL_MODULES=` on amd64
MFC after:	1 month
Sponsored by:	Dell EMC Isilon
Kill MFILES and find things automatically. It turned out to be only 2015-07-03T01:50:26+00:00 Warner Losh imp@FreeBSD.org 2015-07-03T01:50:26+00:00 12f05b84463baacfada5a79eaed061a4899d98aa lightly used. Find the proper .m file when we depend on *_if.[ch] in the srcs line, with seat-belts for false positive matches. This uses make's path mechanism. A further refinement would be to calculate this once, and then pass the resulting _MPATH to modules submakes. Differential Revision: https://reviews.freebsd.org/D2327 
lightly used. Find the proper .m file when we depend on *_if.[ch] in
the srcs line, with seat-belts for false positive matches.  This uses
make's path mechanism. A further refinement would be to calculate this
once, and then pass the resulting _MPATH to modules submakes.

Differential Revision: https://reviews.freebsd.org/D2327
Add VirtIO console driver 2014-10-23T04:47:32+00:00 Bryan Venteicher bryanv@FreeBSD.org 2014-10-23T04:47:32+00:00 6f744ddee48ef123f55831ab9980770bbd667fa1 Support for the multiport feature is mostly implemented, but currently disabled due to some potential races in the hot plug code paths. Requested by: marcel MFC after: 1 month Relnotes: yes 
Support for the multiport feature is mostly implemented, but currently
disabled due to some potential races in the hot plug code paths.

Requested by:	marcel
MFC after:	1 month
Relnotes:	yes
Move most of the 15 variations on generating opt_inet.h and 2014-08-04T22:37:02+00:00 Warner Losh imp@FreeBSD.org 2014-08-04T22:37:02+00:00 aeaed508982227551b2748339033bb2483382b4d opt_inet6.h into kmod.mk by forcing almost everybody to eat the same dogfood. While at it, consolidate the opt_bpf.h and opt_mroute.h targets here too. 
opt_inet6.h into kmod.mk by forcing almost everybody to eat the same
dogfood. While at it, consolidate the opt_bpf.h and opt_mroute.h
targets here too.
Use src.opts.mk in preference to bsd.own.mk except where we need stuff 2014-05-06T04:22:01+00:00 Warner Losh imp@FreeBSD.org 2014-05-06T04:22:01+00:00 c6063d0da8e1f8d8452b0c2ee1c7ad718c1a7052 from the latter. 
from the latter.
Add very simple virtio_random(4) driver to harvest entropy from host 2014-01-18T06:14:38+00:00 Bryan Venteicher bryanv@FreeBSD.org 2014-01-18T06:14:38+00:00 10c401805724439cf6002a20b5da029c62fa90bb Reviewed by: markm (random bits only) 
Reviewed by:	markm (random bits only)