Please fix the email client. The email is in non-text format.
From: Zhu, Lingshan <lingshan.zhu@intel.com>
Sent: Tuesday, October 24, 2023 3:40 PM
To: Parav Pandit <parav@nvidia.com>; Michael S. Tsirkin <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>; virtio-comment@lists.oasis-open.org; cohuck@redhat.com; sburla@marvell.com; Shahaf Shuler <shahafs@nvidia.com>; Maor Gottlieb <maorg@nvidia.com>; Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [virtio-comment] Re: [PATCH v1 3/8] device-context: Define the device context fields for device migration
On 10/23/2023 6:26 PM, Parav Pandit wrote:
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.
so, let's not take SIOV into consideration for this topic.
and we are not introducing a new device type here.
It does not matter.
you citation is in that section.
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.
so, still, I am not introducing a new type of device, right?
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.
In the title "new device"
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.
That section applies to new device with its title "Appendix B. Creating New Device Types"
And I agree we should modify this section, should remove this limitation.
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?
Have not we discussed these before?
|