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.