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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

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.

and we are not introducing a new device type here.

For future device and future functionalities, let's discuss when they 
are implementing, on their series.
>   
> > 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.
> > 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"!!!!!!
> > > > 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.