You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vhost_user: fix replies without GET_PROTOCOL_FEATURES
I observed hangs in the following situation when using Cloud
Hypervisor with virtiofsd:
1. Start virtiofsd
2. Start Cloud Hypervisor instance 1, connected to virtiofsd.
3. Start Cloud Hypervisor instance 2, waiting for migration.
4. Migrate VM from Cloud Hypervisor instance 1 to 2.
5. Start virtiofsd again.
The hangs happened because Cloud Hypervisor remembered, as part of the
migration data, which vhost-user protocol features the backend for its
fs device supported. Instance 2 therefore never sent
GET_PROTOCOL_FEATURES to the second invocation of virtiofsd. This
should work, but it didn't, because update_reply_ack_flag() checked
whether self.protocol_features contained GET_PROTOCOL_FEATURES, but
self.protocol_features is only filled in when GET_PROTOCOL_FEATURES is
called. As a result, Cloud Hypervisor expected a reply that virtiofsd
would never send.
Since REPLY_ACK is handled entirely by the vhost-user library, and not
by the backend, there's no need to ask the backend whether it supports
REPLY_ACK in the first place, so we can just drop the check for that
from update_reply_ack_flag(). We know that we always support it, so
we just need to check whether the backend has acked it. This fixes
the hang described above.
Since we will now always reply if the backend acks the feature,
REPLY_ACK is now always included in the set of features returned by
GET_PROTOCOL_FEATURES, just like with XEN_MMAP (when enabled).
Signed-off-by: Alyssa Ross <[email protected]>
0 commit comments