Hi, Recently bhyve got virtio-9p support. Modeling it appears to be pretty straight-forward, but probably I'm missing something, so decided to discuss first before proceeding with the implementation. On the host side it looks like this: bhyve .... -s 25:0,virtio-9p,distfiles=/workspace/distfiles Mounting it in a (Linux) guest looks this way: mount -t 9p distfiles /mnt/distfiles lspci(8) shows it like this: 00:1f.0 SCSI storage controller: Red Hat, Inc. Virtio filesystem Subsystem: Red Hat, Inc. Virtio filesystem Flags: bus master, fast devsel, latency 64, IRQ 20 I/O ports at 2200 [size=512] Memory at c2004000 (32-bit, non-prefetchable) [size=8K] Expansion ROM at c0007000 [virtual] [disabled] [size=2K] Capabilities: [40] MSI-X: Enable+ Count=2 Masked- Capabilities: [4c] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel driver in use: virtio-pci I was thinking about presenting it like this: <filesystem type='mount'> <driver type='virtiofs'/>

<source dir='/workspace/distfiles'> <target dir='distfiles'/> </filesystem> There's also an optional <readonly/> element for readonly mounts, which is also supported by bhyve.

Daniel P. Berrangé wrote: > On Tue, Oct 06, 2020 at 06:51:52PM +0400, Roman Bogorodskiy wrote: > > Hi, > > > > Recently bhyve got virtio-9p support. Modeling it appears to be pretty > > straight-forward, but probably I'm missing something, so decided to > > discuss first before proceeding with the implementation. > > > > On the host side it looks like this: > > > > bhyve .... -s 25:0,virtio-9p,distfiles=/workspace/distfiles > > > > Mounting it in a (Linux) guest looks this way: > > > > mount -t 9p distfiles /mnt/distfiles > > > > lspci(8) shows it like this: > > > > 00:1f.0 SCSI storage controller: Red Hat, Inc. Virtio filesystem > > Subsystem: Red Hat, Inc. Virtio filesystem > > Flags: bus master, fast devsel, latency 64, IRQ 20 > > I/O ports at 2200 [size=512] > > Memory at c2004000 (32-bit, non-prefetchable) [size=8K] > > Expansion ROM at c0007000 [virtual] [disabled] [size=2K] > > Capabilities: [40] MSI-X: Enable+ Count=2 Masked- > > Capabilities: [4c] MSI: Enable- Count=1/1 Maskable- 64bit+ > > Kernel driver in use: virtio-pci > > > > I was thinking about presenting it like this: > > > > <filesystem type='mount'> > > <driver type='virtiofs'/> > > This driver type is for virtio-fuse, which is different from virtio-9p. > In QEMU we support type=path and type=handle as two different QEMU > bakends for 9p. Or simply omit "type" entirely and it defaults to > 9p in QEMU. So I think you can just omit "type" for bhyve too. > > > <source dir='/workspace/distfiles'> > > <target dir='distfiles'/> > > </filesystem> > > > > There's also an optional <readonly/> element for readonly mounts, which > > is also supported by bhyve. > > Yep. > > Also consider the "accessmode" attribute - you'll want to validate > whichever value(s) of that make sense given the bhyve impl of 9p. It looks like the bhyve implementation doesn't do any uid/gid remapping, i.e. if I chown file on the host, I see same numeric ids (but they corresponding to different users/groups on my test Linux guest compared to the FreeBSD host). The same happens when I chown files in the guest and verify results in the host. Sounds like 'passthrough' is the right choice for this behavior?