On 06.10.23 17:17, Alex Bennée wrote:
Hanna Czenczek <hre...@redhat.com> writes:
On 06.10.23 12:34, Michael S. Tsirkin wrote:
On Fri, Oct 06, 2023 at 11:47:55AM +0200, Hanna Czenczek wrote:
On 06.10.23 11:26, Michael S. Tsirkin wrote:
On Fri, Oct 06, 2023 at 11:15:55AM +0200, Hanna Czenczek wrote:
On 06.10.23 10:45, Michael S. Tsirkin wrote:
On Fri, Oct 06, 2023 at 09:48:14AM +0200, Hanna Czenczek wrote:
On 05.10.23 19:15, Michael S. Tsirkin wrote:
On Thu, Oct 05, 2023 at 01:08:52PM -0400, Stefan Hajnoczi wrote:
On Wed, Oct 04, 2023 at 02:58:57PM +0200, Hanna Czenczek wrote:
<snip>
What I’m saying is, 923b8921d21 introduced SET_STATUS calls that broke all
devices that would implement them as per virtio spec, and even today it’s
broken for stateful devices. The mentioned performance issue is likely
real, but we can’t address it by making up SET_STATUS calls that are wrong.
I concede that I didn’t think about DRIVER_OK. Personally, I would do all
final configuration that would happen upon a DRIVER_OK once the first vring
is started (i.e. receives a kick). That has the added benefit of being
asynchronous because it doesn’t block any vhost-user messages (which are
synchronous, and thus block downtime).
Hanna
For better or worse kick is per ring. It's out of spec to start rings
that were not kicked but I guess you could do configuration ...
Seems somewhat asymmetrical though.
I meant to take the first ring being started as the signal to do the
global configuration, i.e. not do this once per vring, but once
globally.
Let's wait until next week, hopefully Yajun Wu will answer.
I mean, personally I don’t really care about the whole SET_STATUS
thing. It’s clear that it’s broken for stateful devices. The fact
that it took until 6f8be29ec17d to fix it for just any device that
would implement it according to spec to me is a strong indication that
nobody does implement it according to spec, and is currently only used
to signal to some specific back-end that all rings have been set up
and should be configured in a single block.
I'm certainly using [GS]ET_STATUS for the proposed F_TRANSPORT
extensions where everything is off-loaded to the vhost-user backend.
How do these back-ends work with the fact that qemu uses SET_STATUS
incorrectly when not offloading? Do you plan on fixing that?
(I.e. that we send SET_STATUS 0 when the VM is paused, potentially
resetting state that is not recoverable, and that we set DRIVER and
DRIVER_OK simultaneously.)
Hanna
