[Top][All Lists]

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

Re: [Qemu-devel] [PATCH for-4.0 0/6] vhost-user-blk: Add support for bac

From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH for-4.0 0/6] vhost-user-blk: Add support for backend reconnecting
Date: Thu, 13 Dec 2018 10:58:43 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 2018/12/12 下午5:18, Yongji Xie wrote:
Ok, then we can simply forbid increasing the avail_idx in this case?

Basically, it's a question of whether or not it's better to done it in
the level of virtio instead of vhost. I'm pretty sure if we expose
sufficient information, it could be done without touching vhost-user.
And we won't deal with e.g migration and other cases.

OK, I get your point. That's indeed an alternative way. But this feature seems
to be only useful to vhost-user backend.
I admit I could not think of a use case other than vhost-user.

   I'm not sure whether it make sense to
touch virtio protocol for this feature.
Some possible advantages:

- Feature could be determined and noticed by user or management layer.

- There's no need to invent ring layout specific protocol to record in
flight descriptors. E.g if my understanding is correct, for this series
and for the example above, it still can not work for packed virtqueue
since descriptor id is not sufficient (descriptor could be overwritten
by used one). You probably need to have a (partial) copy of descriptor
ring for this.

- No need to deal with migration, all information was in guest memory.

Yes, we have those advantages. But seems like handle this in vhost-user
level could be easier to be maintained in production environment. We can
support old guest. And the bug fix will not depend on guest kernel updating.

Yes. But the my main concern is the layout specific data structure. If it could be done through a generic structure (can it?), it would be fine. Otherwise, I believe we don't want another negotiation about what kind of layout that backend support for reconnect.



reply via email to

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