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

å 2023/10/26 14:22, Michael S. Tsirkin åé:
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
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.

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".

To me, this looks more like a transport. Hypervisors can trap and forward it to admin virtqueue. This somehow duplicates with the idea of transport q over admin.

         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.

Could go either way, but complex functionality like live migration
can benefit from a rich interface.

That's my understanding as well.


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