Re: [virtio-comment] Re: [PATCH 0/2] Selective queue enabling

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 6/14/2023 12:32 PM, Parav Pandit wrote:
> > From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > Sent: Wednesday, June 14, 2023 12:27 AM
> > > If a device has assumed that queue_reset must be done after DRIVER_OK
> > > stage because until that point the device is not "live", Such device needs the
> > fix.
> > I think queue_reset just resets the queue and its fields including the
> > queue_enable. DRIVER_OK is not a must for performing a queue_reset, My
> > understanding is:
> > - before DRIVER_OK, the driver can re-config the queue anytime, doesn't need
> > a reset_queue
> Before DRIVER_OK stage, to reconfigure a queue, driver needs to write queue_enable = 0.
> This is not allowed in the spec.
> So driver need to use queue_reset to reconfigure.
The spec requires the driver config all other fields before set 
queue_enable.
I am not sure whether there are real occurring cases that re-config the vq
fields between queue_enable and DRIVER_OK in the initialization.

But I agree maybe we should allow set queue_enable = 0.

This reset may happen after DRIVER_OK.
> > - after DRIVER_OK, the driver has to reset the queue to re-config the queue.
> > Because a queue is considered alive when both DRIVER_OK && queue_enable,
> > and resetting a queue also set queue_enable to zero.
> >
> > At the end of the migration, hypervisor should reset the queues and config the
> > queues with the guest configurations and enable the queues, right?
> The migration for non vdpa world would not require any of the queue enable/disable flow because device is migrated (paused) with its current state.
> And it can resume from where it left off.
For non-vdpa cases, it still require to migrate the states like MQ which 
is controlled by cvq.