* Johannes Berg (johan...@sipsolutions.net) wrote: > On Wed, 2019-09-11 at 20:15 +0100, Dr. David Alan Gilbert wrote: > > > > Extend the protocol slightly, so that a message can be used for kick > > > and call instead, if VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS is > > > negotiated. This in itself doesn't guarantee synchronisation, but both > > > sides can also negotiate VHOST_USER_PROTOCOL_F_REPLY_ACK and thus get > > > a reply to this message by setting the need_reply flag, and ensure > > > synchronisation this way. > > > > I'm confused; if you've already got REPLY_ACK, why do we need anything > > else? We already require the reply on set_mem_table as part of > > postcopy. > > Hmm? How's this related to set_mem_table? > > For simulation purposes, I need the kick and call (and error perhaps > though it's not really used by anyone now it seems) to be synchronous > messages instead of asynchronous event FD pushes. > > But I think enough words have been expended on explaining it already, if > I may kindly ask you to read the discussions with Stefan and Michael > here: > > https://lore.kernel.org/qemu-devel/20190902121233.13382-1-johan...@sipsolutions.net/
Ah OK. You're actually using the same trick of using REPLY_ACK/need_reply to make it synchronous that set_mem_table does; that makes sense - but then new calls are getting it to actually process some data/commands on the ring itself? Dave > Thanks, > johannes > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
