On Wed, 22 Apr 2026 at 03:16, Jorge Moreira <[email protected]> wrote: > > On Tue, Apr 21, 2026 at 2:12 PM Stefan Hajnoczi <[email protected]> wrote: > > > > On Mon, Apr 20, 2026 at 05:48:13PM -0700, Jorge Moreira wrote: > > > While starting the vrings on SET_VRING_KICK could solve the state > > > machine issue, it still won't notify the back-end that buffers are > > > ready (the driver won't do this). Non-polling back-ends depend on this > > > kick, especially for queues where data flows only from the driver to > > > the back-end. Most implementations likely attempt to read from the > > > queue only after receiving the kick. > > > > This is an interesting question to clarify in the spec.
Yep, which is in part related to what I wrote in the other reply: "I think the main issue to clarify is what the device should do when the vrings are configured, but the driver has already been initialized (which is usually the case after migration)." > > > > Stefan > > This is the question that interests me most, to be honest. I'd rather > have the discussion about when to activate the vrings in a different > thread and keep this one focused on whether the front-end should send > the kick or if the back-end is expected to check if there are "new" > buffers in the vring after restore. > IMO we don't need anything from the VMM. When the device receives SET_VRING_KICK, it can check if the vring already contains buffers (and this is the part we might need to clarify) and wake-up the other threads (or always wake-ups them, as crosvm does IIUC, and let them perform this check). After sending the SET_VRING_KICK message to the device, the VMM has the exact same knowledge of the vring state as the device, therefore, it's still unclear to me why we need to inject that kick. Stefano
