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

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Monday, October 23, 2023 3:44 PM
> 
> On 10/23/2023 6:01 PM, Parav Pandit wrote:
> >
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Monday, October 23, 2023 3:18 PM
> >
> >>> No. Please read the response carefully.
> >>> I said 'For non-backward compatible SIOV device of the future, yes,
> >>> virtio-pci
> >> common config (non init registers) should be moved to a vq, located
> >> on the member device directly.'
> >>> Notice the 'member device directly'.
> >>> Not the PF admin vq.
> >> I think this is a question to Michael and he answered.
> >>
> >> We are talking about PCI, not SIOV, for SIOV we need transport vq.
> >>
> > Hypervisor for future device and future functionality must not get involved in
> looking the device configuration.
> > Hence, as long as transport vq is located on the SIOV device itself for non-
> backward items, it is fine to transport SIOV configuration.
> > For backward compatibility purpose, one will be able to use the aq of the
> owner device. No need to create a new transport VQ.
> > To create a another transport vq, need to clarify the limitations of aq that
> transport vq can overcome, and why aq cannot be extended to overcome it.
> SIOV and transport vq is not related to this topic, don't mix them.
> 
> and admin vq is not a must for live migration.

Ok. You raised the point of transport vq...

>
All repeat points, not leading anywhere for you nor me.
 
> and we are not introducing a new device type here.
> 
It does not matter.

> For future device and future functionalities, let's discuss when they are
> implementing, on their series.
The new device will inherit the "basic functionality non init time register"...
So please donât propose to implement such.

> >
> >> Here again, we are introducing basic facilities for live migration,
> >> and the implementation is transport-specific.
> > Not relevant comment.
> >
> >>>> 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.
> >>>>
> >>> And that control path is only for the init time configuration as
> >>> correctly listed in the virtio spec as,
> >>>
> >>> " Device configuration space should only be used for
> >>> initialization-time
> >> parameters.".
> >> don't you know new field reset_vq is introduced to virtio common cfg?
> >> This is not only for initialization, right?
> > Right. It was unfortunate and also it was last moment entry that we had fixed
> in reset register polarity.
> Appendix B. Creating New Device Types, and we are not introducing new device
> type.
The concept still applies to existing device type.
It is illogical otherwise.

> >
> >> and your citation is from Appendix B. Creating New Device Types, are
> >> we creating a new device type?
> > That is guidance for the new device creation on "how to use config space?"
> > It equally applied to existing devices too to not grow.
> > The section is equally helpful for new creators and for extending devices like
> you and me to understand what not to put in config space.
> this does not make any sense, if you stick to the wording, then let me repeat
> again "Appendix B. Creating New Device Types"!!!!!!
Sorry, your implying is: new device type should be efficient and existing one can make it further bad. Does not make sense to me.

It is fully logical to have only init time things in the config registers as done today in the spec for existing and new devices.

I would be happy to extend B.5 Device improvements to capture it too.

> >
> >>>> 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.
> >>>>
> >>> Can you please explain via virtqueue cannot be used for DMA bulk
> >>> data
> >> transfer as listed in virtio spec.
> >>> " The mechanism for bulk data transport on virtio devices is
> >>> pretentiously
> >> called a virtqueue"
> >> what is your point? vq can do DMA, so what?
> > I am asking,
> > If there is AQ on the member device, can you use it? If not, what is the
> technical reason(s) to not use it.
> Repeated for many times, QOS, nested and so on.
Why would there be any QoS when the AQ is on the member device for non-passthrough use case?
Why nested won't work when the AQ is on the member device for non-passthrough use case?