[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]