VirtioFS support for an alternative to 9P for sharing folder

[crab2313]

[crab2313]

Or support an option for disabling shared folder mounting for kernel without 9p virtio support.

[danobi]

Disabling shared directory support might make sense for an image target, but IIUC almost all distros ship module support for 9pfs. For the kernel target, we need some way to map userspace into the guest. I'd need to take a closer look at virtiofs to see if it'd work, but I'm not sure we can disable shared directory support altogether for kernel targets.

[danielocfb]

I think that actually virtiofs support is less likely to be present by default. I haven't done a comprehensive survey or anything of that sort, but the Arch kernel built as part of vmtest for example seems to compile that support into a module, which makes it unusable from what I gather (we don't have initrd infrastructure). Similar issue for Fedora, it seems (though it's harder to verify because it does not expose a config from the kernel and I haven't tried to dig out what it is built with).

That being said, I am looking at using it to address #83. Wondering if we should just switch over or make virtiofs vs. 9p configurable?

[danobi]

But don't we control the guest kernel? We already have instructions for users to build their guest kernels with a few configs set to =y. Virtiofs module on host shouldn't even be used IIUC. Since on host side it's a FUSE.

[d-e-s-o]

But don't we control the guest kernel? We already have instructions for users to build their guest kernels with a few configs set to =y.

I mean yes, we can always tell users what is necessary. But at the same time there is big benefit in being able to just plug in pretty much any distro kernel floating around, in my opinion. Wider compatibility is just a nice-to-have.

Edit: But if we are solely focused on the host kernel, then yes, it may be a win.

That being said, I'd be totally onboard with ditching 9P completely, assuming VirtioFS provides some tangible benefits (hopefully without any downsides other than the above, hopefully)

[danobi]

Don't most distros already build 9p support as =m?

dlxu@dlxu-fedora~ $ grep 9P /boot/config-$(uname -r)
CONFIG_NET_9P=m
CONFIG_NET_9P_FD=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_XEN=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
CONFIG_VIDEO_MT9P031=m
CONFIG_9P_FS=m
CONFIG_9P_FSCACHE=y
CONFIG_9P_FS_POSIX_ACL=y
CONFIG_9P_FS_SECURITY=y

So virtiofs as =m wouldn't really regress anything.

Have you found any distro kernels that can plug and play with vmtest?

[danobi]

Virtiofs is also said to be faster. Could be nice if true.

[d-e-s-o]

Don't most distros already build 9p support as =m?

I don't know. But looking at the configuration that you use for archlinux, it has:

$ cargo run -- -k bzImage-v6.6-archlinux 'sh -c "zcat /proc/config.gz | grep NET_9P"'
CONFIG_NET_9P=y
CONFIG_NET_9P_FD=m
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_XEN=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set

On the other hand, it has CONFIG_VIRTIO_FS=m and I had to change that to y in order to get stuff booting with / being on VirtioFS (at least I believe that was the crux of the matter -- evidentally a bunch of other options got toggled as well).

I don't have (or, personally, particularly care about) other kernels, because I always build my own anyway.

[d-e-s-o]

dlxu@dlxu-fedora~ $ grep 9P /boot/config-$(uname -r)
CONFIG_NET_9P=m

And does that kernel work with vmtest?

Edit: Just to clarify, I was under the impression that most distro kernels would work with vmtest. But if they don't then it's fine as well and there would be no regression.

[danobi]

Nope, failed:

$ vmtest -k /boot/vmlinuz-$(uname -r) -- uname -r
=> vmlinuz-6.9.5-100.fc39.x86_64
===> Booting
[    0.510964]  mount_root_generic+0x1ac/0x360
[    0.511181]  prepare_namespace+0x69/0x280
[    0.511389]  kernel_init_freeable+0x453/0x510
[    0.511596]  ? __pfx_kernel_init+0x10/0x10
[    0.511793]  kernel_init+0x1a/0x1d0
[    0.511963]  ret_from_fork+0x31/0x50
[    0.512139]  ? __pfx_kernel_init+0x10/0x10
[    0.512356]  ret_from_fork_asm+0x1a/0x30
[    0.512611]  </TASK>
[    0.512830] Kernel Offset: 0xe000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

[danobi]

Edit: Just to clarify, I was under the impression that most distro kernels would work with vmtest. But if they don't then it's fine as well and there would be no regression.

Haha, well I had the exact opposite impression.

[d-e-s-o]

Edit: Just to clarify, I was under the impression that most distro kernels would work with vmtest. But if they don't then it's fine as well and there would be no regression.

Haha, well I had the exact opposite impression.

Ah okay. Are the provided Arch and Fedora kernels not based on the respective stock distro config then?

[danobi]

I think I took the stock configs and changed the required ones from =m -> =y