At Thu, 24 Oct 2019 13:32:59 +0900, Ryota Ozaki <ozaki.ryota%gmail.com@localhost> wrote: Subject: Re: File sharing over virtio-9p > > > A NetBSD guest can mount the exported directory with mount_9p. > > > > mount_9p -cu /dev/vio9p0 /mnt/9p So I finally got a chance to try this the other day after uncommenting the config in GENERIC: diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC index b9d864680b40..ea0770936914 100644 --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -1133,7 +1133,7 @@ viocon* at virtio? # Virtio serial device vioif* at virtio? # Virtio network device viornd* at virtio? # Virtio entropy device vioscsi* at virtio? # Virtio SCSI device -#vio9p* at virtio? # Virtio 9P device +vio9p* at virtio? # Virtio 9P device # Hyper-V devices vmbus* at acpi? # Hyper-V VMBus It seemed to work wonderfully and seemed a bit faster than a QEMU usb umass block device (e.g. emulated CD/ROM or emulated USB stick) in scenario I tried it in, which was macOS with UTM (and QEMU doing the I/O), and with the shared directory in an APFS filesystem on fast SSD. [ 1.053094] virtio4 at pci0 dev 8 function 0 [ 1.053094] virtio4: 9P transport device (id 9, rev. 0x00) [ 1.053094] vio9p0 at virtio4: features: 0x10000001<INDIRECT_DESC,MOUNT_TAG> [ 1.053094] virtio4: allocated 24576 byte for virtqueue 0 for vio9p, size 128 [ 1.053094] virtio4: using 16384 byte (1024 entries) indirect descriptors [ 1.053094] vio9p0: tagged as share I used the mount to do an upgrade of the VM from the release just built on macOS. (as an aside it didn't go as fast as I thought it should and 'systat vmstat' showed it wasn't keeping the devices fully occupied) However I did another reboot to get back to multi-user mode in the VM and I'm now greeted with the following error: # mount_9p -cu /dev/vio9p0 /9pfs/ mount_9p: Rattach not received, got 107 The kernel message in the new kernel look identical: [ 1.016612] virtio4 at pci0 dev 8 function 0 [ 1.016612] virtio4: 9P transport device (id 9, rev. 0x00) [ 1.016612] vio9p0 at virtio4: features: 0x10000001<INDIRECT_DESC,MOUNT_TAG> [ 1.016612] virtio4: allocated 24576 byte for virtqueue 0 for vio9p, size 128 [ 1.016612] virtio4: using 16384 byte (1024 entries) indirect descriptors [ 1.016612] vio9p0: tagged as share The only thing that it was a VM reboot, and maybe QEMU (which didn't restart) gets left in an unusable state? Trying a "cold" reboot now..... Ah ha, yes, that was the problem: # mount_9p -cu /dev/vio9p0 /9pfs # df Filesystem 1K-blocks Used Avail %Cap Mounted on /dev/dk1 27322780 6807586 19149056 26% / /dev/dk3 5082862 601362 4227358 12% /var /dev/dk5 20332078 62498 19252978 0% /home /dev/dk4 60996394 612850 57333726 1% /usr/pkg kernfs 1 1 0 100% /kern ptyfs 1 1 0 100% /dev/pts procfs 4 4 0 100% /proc tmpfs 2096140 4 2096136 0% /var/shm /dev/vio9p0 0 0 0 100% /9pfs # mount /dev/dk1 on / type ffs (log, local) /dev/dk3 on /var type ffs (log, local) /dev/dk5 on /home type ffs (log, local) /dev/dk4 on /usr/pkg type ffs (log, local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) procfs on /proc type procfs (local) tmpfs on /var/shm type tmpfs (local) /dev/vio9p0 on /9pfs type puffs|9p I wonder is there anything NetBSD, i.e. vio9p(4), can do to cleanly shut down the 9p connection and allow it to be reused without having to restart the host QEMU process? This would be nice as then a VM could reboot itself without having to use the host tools to restart. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpvXJequvVf4.pgp
Description: OpenPGP Digital Signature