Re: [Virtio-fs] (no subject)

[Hanna Czenczek]

On 17.10.23 09:49, Viresh Kumar wrote:
> On 13-10-23, 20:02, Hanna Czenczek wrote:
> > On 10.10.23 16:35, Alex Bennée wrote:
> > > I was going to say there is also the rust-vmm vhost-user-master crates
> > > which we've imported:
> > >
> > >     https://github.com/vireshk/vhost
> > >
> > > for the Xen Vhost Frontend:
> > >
> > >     https://github.com/vireshk/xen-vhost-frontend
> > >
> > > but I can't actually see any handling for GET/SET_STATUS at all which
> > > makes me wonder how we actually work. Viresh?
> > As far as I know the only back-end implementation of F_STATUS is in DPDK.
> > As I said, if anyone else implemented it right now, that would be dangerous,
> > because qemu doesn’t adhere to the virtio protocol when it comes to the
> > status byte.
> Yeah, none of the Rust based Virtio backends enable `STATUS` in
> `VhostUserProtocolFeatures` and so these messages are never exchanged.
>
> The generic Rust code for the backends, doesn't even implement them.
> Not sure if they should or not.

It absolutely should not, for evidence see this whole thread.  qemu 
sends a SET_STATUS 0, which amounts to a reset, when the VM is merely 
paused[1], and when it sets status bytes, it does not set them according 
to virtio specification.  Implementing it right now means relying on and 
working around qemu’s implementation-defined spec-breaking behavior.  
Also, note that qemu ignores feature negotiation response through 
FEATURES_OK, and DEVICE_NEEDS_RESET, so unless it’s worth working around 
the problems just to get some form of DRIVER_OK information (note this 
information does not come from the driver, but qemu makes it up), I 
absolutely would not implement it.

[1] Notably, it does restore the virtio state to the best of its 
abilities when the VM is resumed, but this is all still wrong (there is 
no point in doing so much on a pause/resume, it needlessly costs time) 
and any implementation that does a reset then will rely on the 
implementation-defined behavior that qemu is actually able to restore 
all the state that the back-end would lose during a reset. Notably, 
reset is not even well-defined in the vhost-user specification.  It was 
argued, in this thread, that DPDK works just fine with this, precisely 
because it ignores SET_STATUS 0.  Finally, if virtiofsd in particular, 
as a user of the Rust crates, is reset, it would lose its internal 
state, which qemu cannot restore short of using the upcoming migration 
facilities.