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 11:58, Parav Pandit åé:

From: Jason Wang <jasowang@redhat.com>
Sent: Thursday, October 26, 2023 6:27 AM

On Wed, Oct 25, 2023 at 4:33âPM Michael S. Tsirkin <mst@redhat.com> wrote:
On Tue, Oct 24, 2023 at 06:27:04PM +0800, Zhu, Lingshan wrote:

On 10/23/2023 7:32 PM, Michael S. Tsirkin wrote:

     On Mon, Oct 23, 2023 at 06:03:10PM +0800, Zhu, Lingshan wrote:

         config space, MMIO, registers work for years, what is wrong with them?

     Nothing as such. They don't seem to be appropriate for all use-case
     where people want to utilize virtio. I think a new transport
     will be needed to address these.

New transport for new type of devices for sure, like transport vq for SIOV.

I agree admin vq or admin cmds are useful in some use cases, that is
another story, should be case by case.

For now, let's don't talk about all-use cases, just for current
task, for live migration.

So IMHO, I still think we should use config space registers to
control live migration process.

No because it forces integrating migration process with device driver.
Which is ok for some use-cases but not all of them.  Find some other
control plane for this.

                 Config space is control path, DMA is data-path, let's better not mix
                 we never expect to use config space to transfer data.

                 So we need DMA to transfer data, for example I take advantages of
device DMA
                 to logging dirty pages, This also applies to in-flight descriptors.

             As long as you do, I personally see little benefit to retrieve parts of
             state with memory mapped accesses.

         registers only control, and I personally believe a single register is much
         than processing admin commands, more light-weight, more reliable,
         for years.

     Yea. It would be, if we could do everything through that register.
     But we can't really. Migration has too much data to pass around
     for that to be reasonable.

data are not transferred by registers, they only control.

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.

For passthrough member devices, this admin commands to be transported via the owner device by the migration driver which sits outside of the guest VM.

If this basic requirement is not clear it's pointless to discuss further.

So my question is not limited to devices that is modeled as group/owner.

How is the passthrough device defined? It is defined as [1].

Can non passthrough device modes such as vdpa also use these admin commands from the owner device?
Sure, why not?

That's fine but it's not my question again.


[1] PH0PR12MB5481EA6A4D0C64C5AF6D3A57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/">https://lore.kernel.org/virtio-comment/PH0PR12MB5481EA6A4D0C64C5AF6D3A57DCD4A@PH0PR12MB5481.namprd12.prod.outlook.com/

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