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 Thu, Oct 26, 2023 at 2:23âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Oct 26, 2023 at 08:56:47AM +0800, Jason Wang wrote:
> > > > We transfer data by DMA, the device writes DMA dirty pages information(bitmap)
> > > > to host isolated memory region.
> > > >
> > >
> > >
> > > If you do that then I don't see any reason not to use admin
> > > commands for that - either through a vq or a simpler
> > > interface.
> >
> > I think we need to agree that admin commands are the only interface
> > for any future features before we can have an agreement here.
>
> I don't think that needs to be the case. I do think that if
> your goal is a separate channel from normal device operation
> then this is what admin commands have been designed for.

Sure, but the question is. If we want to have a new feature X, should
it only go with admin commands or not?

>
> > My understanding is that it is optional for the transport that
> > requires administrative commands like provisioning etc. It is not
> > necessarily the interface for new features.
>
> Yes. And migration is IMO sufficiently "like provisioning".

Well, I basically mean provisioning a virtio device while the proposal
here is to provision state which has been done by the existing
transport.

Not sure if you've noticed or not, this proposal is actually a partial
implementation of a transport.

>
> > >
> > >
> > > >
> > > >         Config space interfaces are fundamental for virtio-pci.
> > > >
> > > >
> > > >     They are in fact fundamental to virtio. Multiple transports to
> > > >     use config space are also fundamental.
> > > >
> > > > I agree. So I also agree to build admin vq live migration solution based on our
> > > > basic facilities, as Jason ever proposed.
> > >
> > >
> > > I'm not sure it's even a vq. I suggest a minimal interface to send
> > > admin commands. Could be used by migration, as transport, and more.
> > >
> >
> > It's better if we can do that below the layer of admin commands. For
> > example, we don't stick device status with any specific interface. We
> > can keep doing things like this.
> >
> > Thanks
>
> Could go either way, but complex functionality like live migration
> can benefit from a rich interface.

Ok.

Thanks


>
> --
> MST
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>



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