On Tue, Aug 18, 2026 at 11:23 PM Akihiko Odaki <[email protected]> wrote: > > > + > > + if (r < 0) { > > + /* VQ or handler is broken. Do not set guest notifier > > */ > > This comment is extraneous. It is obvious that event_notifier_set() > below is not called, and it is same with the existing error path below. > > What matters here is the difference with the existing error path. Why > doesn't it call virtqueue_fill() nor virtqueue_flush()? They need to be > addressed here. > > Regards, > Akihiko Odaki >
Here, apart from not calling event_notifier_set (not notifying the guest), we are also not calling vhost_svq_enable_notification, so the device is directed not to send any more call notifications. If the guest isn't receiving notifications, and the device isn't sending them, is there a purpose to flushing the current element? With the current implementation, I'm not sure there is a path to re-enable calls on either the front-end or back-end, but maybe a case could be made that it's good hygiene to flush the known bad element? For now, I will add the calls to add and flush the element Thank you! Connor
