[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vhost reply_ack negotiation (a.k.a differences in vhost-user behavio

From: Alex Bennée
Subject: Re: vhost reply_ack negotiation (a.k.a differences in vhost-user behaviour with libvhost-user and vhost-user-backend.rs)
Date: Mon, 22 Feb 2021 13:21:04 +0000
User-agent: mu4e 1.5.8; emacs 28.0.50

Dr. David Alan Gilbert <dgilbert@redhat.com> writes:

> * Alex Bennée (alex.bennee@linaro.org) wrote:
>> Hi,
>> I finally got a chance to get down into the guts of vhost-user while
>> attempting to port my original C RPMB daemon to Rust using the
>> vhost-user-backend and related crates. I ended up with this hang during
>> negotiation:
>>   startup
>>   vhost_user_write req:1 flags:0x1
>>   vhost_user_read_start
>>   vhost_user_read req:1 flags:0x5
>>   vhost_user_backend_init: we got 170000000


>>   vhost_user_write req:15 flags:0x1
>>   vhost_user_read_start
>>   vhost_user_read req:15 flags:0x5
>>   vhost_user_set_protocol_features: 2008
>>   vhost_user_write req:16 flags:0x1
>>   vhost_user_write req:3 flags:0x1
>>   vhost_user_write req:1 flags:0x1
>>   vhost_user_read_start
>>   vhost_user_read req:1 flags:0x5
>>   vhost_user_write req:13 flags:0x1
>>   kernel initialises device
>>   virtio_rpmb virtio1: init done!
>>   vhost_user_write req:13 flags:0x1
>>   vhost_dev_set_features: 130000000
>>   vhost_user_set_features: 130000000


>>   vhost_user_write req:2 flags:0x1
>>   vhost_user_write req:5 flags:0x9
>>   vhost_user_read_start
>>  - Should QEMU have preserved VhostUserVirtioFeatures::PROTOCOL_FEATURES
>>    when doing the eventual VHOST_USER_SET_FEATURES reply?
>>  - Is vhost.rs being to strict or libvhost-user too lax in interpreting
>>    the negotiated features before processing the ``need_reply`` [Bit 3]
>>    field of the messages?
> I think vhost.rs is being correctly strict - but there would be no harm
> in it flagging that you'd hit an inconsistency if it finds a need_reply
> without the feature.

But the feature should have been negotiated. So unless the slave can
assume it is enabled because it asked I think QEMU is in the wrong by
not preserving the feature bits in it's SET_FEATURES reply. We just gets
away with it with libvhostuser being willing to reply anyway.

>>    in the "list of the ones that do" require replies or do they only
>>    reply when REPLY_ACK has been negotiated as the ambiguous "seealso::"
>>    box out seems to imply?
> set_mem_table gives a reply when postcopy is enabled (and then qemu
> replies to the reply!) but otherwise doesn't.
> (Note there's an issue opened for .rs to support ADD_MEM_REGION
> since it's a lot better than SET_MEM_TABLE which has a fixed size table
> that's small).

Thanks for the heads up.

> Dave
>> Currently I have some hacks in:
>>   https://github.com/stsquad/vhost/tree/my-hacks
>> which gets my daemon booting up to the point we actually need to do a
>> transaction. However I won't submit a PR until I've worked out exactly
>> where the problems are.
>> -- 
>> Alex Bennée

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]