mirror of
https://github.com/cloud-hypervisor/cloud-hypervisor.git
synced 2024-08-21 23:41:15 +00:00
Even if the vhost-user-net device did implement all currently-defined features, it would be very short-sighted to use ::all(), because if a new feature was defined later, the device would start claiming to implement it even though it didn't. More practically, claiming to implement all features breaks using QEMU with the cloud-hypervisor vhost-user-net backend, because QEMU will negotiate VHOST_USER_PROTOCOL_F_SLAVE_REQ, and then break when the communication channel isn't actually set up. I wasn't sure exactly which features the backend should claim to implement, though. Definitely MQ, and I'm fairly certain none of the features I've ommitted are implemented. But I'm not sure about REPLY_ACK. As far as I can tell it should be implemented entirely by the vhost crate, with no cooperation required from the vhost-user-net backend itself, so there should be no reason to let a frontend use it if it wants to. But despite this, neither vhost-user-fs nor vhost-user-blk claims to implement it. Signed-off-by: Alyssa Ross <hi@alyssa.is> |
||
---|---|---|
.. | ||
src | ||
Cargo.toml |