[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
so, let's not take SIOV into consideration for this topic.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 PMNo. Please read the response carefully. I said 'For non-backward compatible SIOV device of the future, yes, virtio-pcicommon 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 inlooking 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 theowner device. No need to create a new transport VQ.To create a another transport vq, need to clarify the limitations of aq thattransport 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.
you citation is in that section.and we are not introducing a new device type here.It does not matter.
so, still, I am not introducing a new type of device, right?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.
In the title "new device"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-timeparameters.". 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 fixedin 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.
That section applies to new device with its title "Appendix B. Creating New Device Types"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 likeyou 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.
Have not we discussed these before?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 datatransfer as listed in virtio spec." The mechanism for bulk data transport on virtio devices is pretentiouslycalled 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 thetechnical 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]