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

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

On 11/1/2023 8:42 AM, Jason Wang wrote:
> On Tue, Oct 31, 2023 at 6:14âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Oct 31, 2023 at 05:42:29PM +0800, Zhu, Lingshan wrote:
> > > > Your answer is not relevant to this discussion at all.
> > > > Why?
> > > > Because we were discussing the schemes where registers are not used.
> > > > One example of that was IMS. It does not matter MSI or MSIX.
> > > > As explained in Intel's commit message, the key to focus for IMS is "queue memory" not some hw register like MSI or MSI-X.
> > > you know the device always need to know a address and the data to send a
> > > MSI, right?
> > So if virtio is to use IMS then we'll need to add interfaces to program
> > IMS, I think. As part of that patch - it's reasonable to assume - we will
> > also need to add a way to retrieve IMS so it can be migrated.
> >
> > However, what this example demonstrates is that the approach taken
> > by this proposal to migrate control path structures - namely, by
> > defining a structure used just for migration - means that we will
> > need to come up with a migration interface each time.
> > And that is unfortunate.
> >
> > Compare to the trap and emulate approach for config space and we don't
> > need a new interface, we just make each field R/W.
> > So I feel this is something to think about, and address.
> > Ideas?
> Something like we've done for transportq in the past? (by just adding
> the get commands):
>
> https://lore.kernel.org/all/29533940-0345-4a84-fcc7-f42d914dc28d@intel.com/T/#mbfe209b96e1dda88ed7aae04d25b12026a7b5364
Exactly! and I will continue this work once our live migration proposal 
merged.
> Thanks
>
> > --
> > MST