OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Thanks

>
> --
> MST
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]