Re: DAX support in virtiofsd
Hanna Czenczek <[email protected]> Wed, 20 Aug 2025 10:34:08 +0200
| Newsgroups | dev.linux.lists.virtio-fs |
|---|---|
| Message-ID | <[email protected]> |
On 19.08.25 23:13, Jeremy Bongio wrote: > Hello, Hi! > My team has been using DAX w/ virtiofsd for read-only devices. Does that mean you already have code for read-only DAX in virtiofsd? (FWIW, we were considering this specific case too, because it wouldn’t have the post-EOF access problem.) > We are > interested in continuing this use case, but support has been removed > upstream for > > * setup/remove mapping in vhost-user rust crate. > https://github.com/rust-vmm/vhost/commit/569ef077facafe21f16c0e65ff826b26d3c9a0b3 > discussion: https://github.com/rust-vmm/vhost/issues/213 > > * as a consequence, setupmapping/removemapping in virtiofsd. > https://gitlab.com/virtio-fs/virtiofsd/-/commit/87f67e84cb032e6f4ce4a9f408b6305f33d2d041 > > The virtio spec already/still contains support for DAX. > > The primary reasons for removing support for this feature in vhost and > virtiofsd appear to be that it is not in the vhost-user spec > (https://www.qemu.org/docs/master/interop/vhost-user.html) and there > are major edge cases not dealt with, so DAX can't be safely used if > the backing store can change in size. > > Some of the major technical challenges to supporting DAX were > discussed in: https://lore.kernel.org/virtio-fs/[email protected]/ > ... > Specifically: >> 1. How to inject SIGBUS when the guest accesses a page that's beyond >> the end-of-file. >> 2. Implementing the vhost-user messages for mapping ranges of files to >> the vhost-user frontend. > I expect the steps to support DAX in virtiofsd are: > > 1. add the necessary vhost-user messages for mapping ranges to the > spec ... What is the RFC process for modifying the vhost standard? > What mailing list should I use? The specification is part of QEMU, so the mailing list is [email protected]. Generally, you just send a patch to the specification (docs/interop/vhost-user.rst in QEMU) to propose additions to the standard. If possible and reasonable, it’s good to accompany it by code that would implement that (in QEMU, and e.g. a link to a private repository of a vhost-user back-end with that implemented). > 2. re-implement vhost-user messages in the vhost-user rust crate > > 3. re-implement setup/remove mapping in virtiofsd. > > 4. implement new vhost-user messages in qemu? > > 5. find solution for safely handling page faults beyond EOF. I don’t think there’s a strict order here; if you want to implement write access, that solution probably has to be found, so delaying it until after the rest may not be ideal. On the other hand, we’d already be happy with just read-only DAX, too. (And steps 1 through 4 may need to be done simultaneously as a proof of concept, to show that potential vhost-user spec changes make sense.) > Can you offer comments, guidance, opinions? Is there resistance to > this work or is it that no one was interested enough to complete it? There is absolutely no resistance to this work, German Maglione and me (virtiofsd maintainers) would be more than happy to assist. FWIW, there’s a virtiofsd “community” call (usually just German and me, hence the quotation marks) every two weeks on Wednesdays 10 am ET (i.e. currently EDT, so 2 pm GMT), including today, on https://meet.google.com/bsx-qnxz-ifz (notes on https://etherpad.opendev.org/p/virtiofs-external-meeting). We’re happy to discuss anything you’d like there, too. (The next call after today would be on Sep 3, but due to KVM Forum, I think it will be skipped.) Hanna