RE: [virtio-comment] Re: [PATCH v1 3/8] device-context: Define the device context fields for device migration

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, November 1, 2023 2:06 PM

> My experience shows we need simple composable and self-contained blocks.
> If we are trying to make hypervisor avoid accessing device memory (which
> seems to be one of key design points behind what you are building) then we
> can't have queue msix vector index migrated in one way and the vector itself in
> a completely different way.
> 
Make sense to include as long as one can use it.

> For example, one of the advantages of using admin commands is that they are
> atomic - so we get a consistent snapshot of the device state.
> But, this goes out of the window if we are referencing a table that is not part of
> that same command output.

To make the device active at destination, one needs both the fields restored as consistent.
Only after that one can make the mode change from stop->active.
Usually, vq is indexing in the table without reading the table content, right?
I can see some device implementation may try to read this table when writing the device context, 
but that would be really hard for device to keep synchronizing VQ with msix entry as in theory vector can be masked.