I saw this initial patch, but was short on time to reply until now. I am still interested in this and keep pursuing it! I was also working on adding the initial support (had a working driver but nothing on the fs side), so I will rebase on your work and continue from there. A question here is what's the best way to avoid parallel work in the future? May I be missing something apart from getting the mails from this list and notifying here when working on something?
I agree with you that DAX seems the most interesting feature to add at this point, so this is what I will be focusing on for now. I have started with some more generic reading on it and will check out the Linux driver implementation to come up with how it could possibly be implemented in OSv. When I have something more concrete (hopefully some point in the next couple of weeks) I will share it here, your feedback will undoubtedly be necessary. Fotis Τη Τρίτη, 11 Φεβρουαρίου 2020 - 1:21:13 π.μ. UTC+2, ο χρήστης Waldek Kozaczuk έγραψε: > > We have just pushed initial implementation of Virtio-FS with this commit - > https://github.com/cloudius-systems/osv/commit/bae4381d1d0558b7a684294e9203864f9652395c. > > This is just a start but enough to for example run simple app from a > directory on Linux host mounted through virtio-FS. > > There are still many outstanding items which I listed here - > https://github.com/cloudius-systems/osv/issues/1062#issuecomment-584400796 > so you if are still interested you can help us implement those. The most > interesting and challenging one is the DAX window which allows directly map > a file from host into guest virtual address space. I am not sure how to > exactly accomplish this in OSv but I guess we would need to create a > mechanism to create a VMA where virtual address range on OSv is mapped to > some physical memory range passed by fuse requests (just my wild guess). > > Waldek > > On Sunday, January 5, 2020 at 1:11:23 AM UTC-5, Waldek Kozaczuk wrote: >> >> It looks like virtio-fs driver would communicate with the hypervisor >> (device) using FUSE protocol. So we would need to incorporate this header - >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h >> . >> >> Per virtio spec ( >> https://stefanha.github.io/virtio/virtio-fs.html#x1-41500011), the >> virtio-fs driver could handle the logic of processing the virtio_fs_req >> requests but the vfs layer would know how to construct specific requests >> like virtio_fs_read_req or something like this. >> >> On Sunday, January 5, 2020 at 12:30:20 AM UTC-5, Waldek Kozaczuk wrote: >>> >>> Hi, >>> >>> On Saturday, January 4, 2020 at 11:08:29 AM UTC-5, fo...@windowslive.com >>> wrote: >>>> >>>> Hello, >>>> >>>> I am Fotis, currently an undergraduate ECE student in Athens, Greece. >>>> >>>> I 've been looking into Virtio-FS and adding support for it in OSv >>>> seems pretty interesting. I have read the documentation in the wiki as >>>> well >>>> as the documentation directory in the repo and I was starting to read the >>>> code for existing filesystems and virtio devices. I 'd like to ask though >>>> if there is any other relevant documentation (or code) you think would be >>>> helpful. >>>> >>>> Also, in addition to the requirements mentioned in the GitHub issue >>>> <https://github.com/cloudius-systems/osv/issues/1062>, are you aware >>>> of any other major blockers that could surface? How difficult and time >>>> consuming do you think this could prove to be in general? >>>> >>> Virtio-FS is definitely in the "bleeding edge" category. It has only >>> been merged into Linux codebase couple of month ago ( >>> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-VirtIO-FS) >>> and I do not think it has been merged into QEMU codebase yet. It is not >>> even part of the last finalized virtio 1.1 spec, I think (will be part of >>> 1.2?). Having said all that, I still think it would be a very big win even >>> if OSv supported some minimal version of it. That is why I suggested >>> starting with the read-only part of it which should make initialial >>> implementation easier. Even that would be super helpful as OSv could read >>> and execute the application code from the host instead of putting them >>> inside of the image (I am not sure what exactly the security implications >>> of it would be). I also think that Firecracker team is planning to add >>> virtio-fs support ( >>> https://github.com/firecracker-microvm/firecracker/issues/1180 and >>> https://github.com/firecracker-microvm/firecracker/pull/1351). >>> >>> As far as how to go about implementing read-only part of virtio-fs in >>> OSv, I would break it down into two major pieces: >>> >>> - virtio driver for virtio-fs per what is in the spec (class >>> inheriting from virtio-driver); look for the examples at virtio-blk.* >>> and >>> virtio-scsi.* under drivers, the class diagrams from this article may >>> help >>> as well - >>> http://blog.osv.io/blog/2019/04/19/making-OSv-run-on-firecraker/ >>> - new vfs layer for virtio-fs - would go under fs; look at rofs >>> implementation >>> https://github.com/cloudius-systems/osv/tree/master/fs/rofs for an >>> example as it implements exactly the subset of VFS operations we would >>> need >>> for read-only version of virtio-fs (please ignore the cache layer logic >>> in >>> rofs as it would not apply to virtio-fs). >>> >>> Now the challenge is that "normal" file system implementations in OSv >>> like ZFS or ROFS can work with any block device and driver like virtio-blk, >>> virtio-scsi, ide, etc using the bio abstraction. For example, see this >>> piece of code in ROFS - >>> https://github.com/cloudius-systems/osv/blob/69a0ce39eb7c5af76bd2c714939c02ceb7ea398f/fs/rofs/rofs_common.cc#L60-L85 >>> >>> - where it simply specifies the offset at and number of bytes to read from >>> the block device. >>> >>> In virtio-fs, as I am guessing (and might be wrong) it would be >>> different as it operates at the vnode level (files and directories) instead >>> of raw block device. So we have a bit of a "conflict of abstractions". This >>> means that new drivers/virtio-fs driver class would NOT implement functions >>> like blk_strategy(), blk_read(), blk_write() that use bio struct, instead >>> it would implement some different interface - not sure what yet. Also, VFS >>> layer for virtio-fs would be more similar to what we do for nfs (see >>> https://github.com/cloudius-systems/osv/blob/master/fs/nfs/nfs_vnops.cc) >>> where we also do not read/write from a block device - instead we read/write >>> over the network using a socket. Obviously, in case of fs/virtiofs it would >>> interact directly with virtio-fs driver, I think. >>> >>> I hope it is good information for starters. As you go along we will >>> guide you more. All in all I do not think implementing the read-only part >>> of virtio-fs would be a big or complicated effort. At least that is what it >>> seems. >>> >>> Regards, >>> Waldek >>> >>>> >>>> Thank you! >>>> >>>> Τη Σάββατο, 27 Απριλίου 2019 - 6:55:06 π.μ. UTC+3, ο χρήστης Waldek >>>> Kozaczuk έγραψε: >>>>> >>>>> It is supposed to be part of VirtIO at some point. I think NEMU (and >>>>> possibly QEMU 4.0) might support it - >>>>> https://github.com/intel/nemu/issues/211. >>>>> >>>>> It would be nice to investigate it a little. >>>>> >>>>> - https://lkml.org/lkml/2018/12/10/615 >>>>> - https://gitlab.com/virtio-fs >>>>> - >>>>> https://lists.oasis-open.org/archives/virtio-dev/201812/msg00073.html >>>>> >>>>> Maybe better long term than 9P FS? >>>>> >>>>> Waldek >>>>> >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/c4f98d80-5212-4e92-bc78-64ce4cf77b0b%40googlegroups.com.
