Re: Is anyone working on VirtFS (FUSE over VirtIO)

Top posting: I think you mean VirtioFS, not VirtFS. The latter is the 9p
thing that dfr is doing, the former is FUSE over VirtIO.  I'll assume you
mean that.

On Sun, Dec 31, 2023 at 8:25 AM David Chisnall <theraven@freebsd.org> wrote:

> On 31 Dec 2023, at 14:36, Alan Somers <asomers@freebsd.org> wrote:
> >
> > On Sun, Dec 31, 2023 at 5:46 AM David Chisnall <theraven@freebsd.org>
> wrote:
> >>
> >> Hi,
> >>
> >> For running FreeBSD containers on macOS, I’m using dfr’s update of the
> 9pfs client code.  This seems to work fine but Podman is in the process of
> moving from using QEMU to using Apple’s native hypervisor frameworks.
> These don’t provide 9pfs servers and instead provide a native VirtFS server
> (macOS now ships with a native VirtFS client, as does Linux).
> >>
> >> I believe the component bits for at least a functional implementation
> already exist (FUSE and a VirtIO transport), though I’m not sure about the
> parts for sharing buffer cache pages with the host.  Is anyone working on
> connecting these together?
> >>
> >> David
> >
> > Nobody that I know of.  And while I understand the FUSE stuff well,
> > I'm shakier on VirtIO and the buffer cache.  Do you think that this is
> > something that a GSoC student could accomplish?
>
> I’m not familiar enough with either part of the kernel to know. A
> competent student with two mentors each familiar with one of the parts
> might, but this is increasingly strategically important. The newer cloud
> container-hosting platforms are moving to lightweight VMs with VirtFS
> because it lets them get the same sharing of container image contents
> between hosts but with full kernel isolation. It would be easy to plug
> FreeBSD in as an alternative to Linux with this support.
>

We shouldn't pin our hopes on GSoC for this. If it is important, it needs
to be funded.


> The VirtFS protocol is less well documented than I’d like, but it appears
> to primarily be a different transport for FUSE messages and so may be quite
> easy to add if the FUSE code is sufficiently abstracted.
>

Yea. The FUSE protocol is going to be the challenge here. For this to be
useful, the VirtioFS support on the FreeBSD  needs to be 100% in the
kernel, since you can't have userland in the loop. This isn't so terrible,
though, since our VFS interface provides a natural breaking point for
converting the requests into FUSE requests. The trouble, I fear, is a
mismatch between FreeBSD's VFS abstraction layer and Linux's will cause
issues (many years ago, the weakness of FreeBSD VFS caused problems for a
company doing caching, though things have no doubt improved from those
days). Second, there's a KVM tie-in for the direct mapped pages between the
VM and the hypervisor. I'm not sure how that works on the client (FreeBSD)
side (though the description also says it's mapped via a PCI bar, so maybe
the VM OS doesn't care).

Now, having said that it's a challenge shouldn't be taken as
discouragement. I think it's going to take advice from a lot of different
people to be successful. It sounds like a fun project, but I'm already
over-subscribed to fun projects for $WORK. I cast no doubt on its
importance.

Warner