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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 19, 2023 at 10:33:15AM +0000, Parav Pandit wrote:
> > From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > Sent: Thursday, October 19, 2023 2:48 PM
> > 
> > On 10/19/2023 5:14 PM, Michael S. Tsirkin wrote:
> > > On Thu, Oct 19, 2023 at 09:13:16AM +0000, Parav Pandit wrote:
> > >>> Oh, really? Quite interesting, do you want to move all config space
> > >>> fields in VF to admin vq? Have a plan?
> > >> Not in my plan for spec 1.4 time frame.
> > >> I do not want to divert the discussion, would like to focus on device
> > migration phases.
> > >> Lets please discuss in some other dedicated thread.
> > > Possibly, if there's a way to send admin commands to vf itself then
> > > Lingshan will be happy?
> > still need to prove why admin commands are better than registers.
> 
> Virtio spec development is not proof based approach. Please stop asking for it.
> 
> I tried my best to have technical answer in [1].
> I explained that registers simply do not work for passthrough mode
> (if this is what you are asking when you are asking prove its better).
> They can work for non_passthrough mediated mode.
> 
> A member device may do admin commands using registers. Michael and I are discussing presently in the same thread.
> 
> Since there are multiple things to be done for device migration, dedicated register set for each functionality do not scale well, hard to maintain and extend.
> A register holding a command content make sense.
> 
> Now, with that, if this can be useful only for non_passthrough, I made humble request to transport them using AQ, this way, you get all benefits of AQ.
> And trying to understand, why AQ cannot possible or inferior?

I think the real limitation is with the SRIOV group type. If using PASID
instead of source id for isolation then we'd need a new group type.
And maybe a simpler interface than virtqueue since it's all
slow path anyway.


> If you have commands like suspend/resume device, register or queue transport simply don’t work, because it's wrong to bifurcate the device with such weird API.
> If you want to biferacate for mediation software, it probably makes sense to operate at each VQ level, config space level. Such are very different commands than passthrough.
> I think vdpa has demonstrated that very well on how to do specific work for specific device type. So some of those work can be done using AQ.
> 
> [1] https://lore.kernel.org/virtio-comment/870ace02-f99c-4582-932f-bd103362dae9@intel.com/T/#m37743aa924536d0256d6b3b8e83a11c750f28794


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/