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

[Jason Wang <jasowang@redhat.com>]

å 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
> > them,
> > > >                  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
> > > >          better
> > > >          than processing admin commands, more light-weight, more reliable,
> > working
> > > >          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.

Thanks


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