On Mon, Sep 09, 2019 at 01:35:19PM +0200, Johannes Berg wrote: > On Sun, 2019-09-08 at 09:13 -0400, Michael S. Tsirkin wrote: > > > > I think the only use for this extension would be for simulation > > > purposes, and even then only combined with the REPLY_ACK and SLAVE_REQ > > > extensions, i.e. you explicitly *want* your virtual machine to lock up / > > > wait for a response to the KICK command (and respectively, the device to > > > wait for a response to the CALL command). > > > > OK so when combined with these, it's OK I think. > > OK. > > > Do we want to force this restriction in code maybe then? > > Unlike in this patch, I was planning to not actually advertise > VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS, and do that only if the user of > the library wants to advertise it, since devices used for simulation > also have to be careful about how they use this. > > However, if I understand correctly we cannot enforce that all of them > are used at the same time - we're the device side, so we only advertise > our features and the master actually sets the ones it wants to use, no? > > The only thing we could do is crash if it wants to use this feature > without the others, but would that really be helpful?
We can return failure from SET_PROTOCOL_FEATURES. We can also fail all following messages. > I'm starting to actually get this working, so I'll post new patches in a > few days or so. > > johannes
