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.


Reply via email to