OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]