> From: Jason Wang <>
> Sent: Monday, October 30, 2023 9:30 AM
>
>
> å 2023/10/26 11:58, Parav Pandit åé:
> >
> >> From: Jason Wang <>
> >> Sent: Thursday, October 26, 2023 6:27 AM
> >>
> >> On Wed, Oct 25, 2023 at 4:33âPM Michael S. Tsirkin <>
> 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.
>
Current proposal is for the group/owner model hw based devices supported by virtio-spec.
I will not debate this further.
Mmio can invent that model when a user really needs it.
>
> > 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.
>
Ok. so one interface is able to serve two use cases now.
Good.
Thanks.
