RE: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Friday, September 22, 2023 8:38 AM

> > Device context has no overlap.
> 
> I can give you one example, e.g debugging.
>
Almost every feature needs debugging. :)
So I am omitting it for time being.

 
> >
> > Dirty page tracking has no overlap. What do you want to profile and monitor?
> In case if you want to profile, it can be used without migration command
> anyway?
> 
> It works like a dirty bit of PTE. We all know it has a broader use case than
> logging. For example, tracking working set and do optimization on
> IOMMU/IOTLB or even device IOTLB.
> 
> 1) Try to prove your facility can only work for one specific cases
> 2) Try to prove your facility can work for more than one cases
> 
> Which one is easier and more beneficial to virtio?
> 
> 
> > If you describe, may be we I can split "device migration" chapter to
> > two pieces, Device management and device migration.
> >
> > Device migration will use these basic facility.
> > Would that help you?
> 
> Definitely, but it needs to be done by not making it under the subsection of
> admin commands, that's it.
> 
> Let me repeat once again here for the possible steps to collaboration:
> 
> 1) define virtqueue state, inflight descriptors in the section of basic facility but
> not under the admin commands
It will be part of the device context such a way that so that one can only read the vq state only instead of full device context.
This will work.

> 2) define the dirty page tracking, device context/states in the section of basic
> facility but not under the admin commands
Great.
Device context is already defined in the basic facility outside of the admin commands in [1].
Current text is around device migration and spec evolves it can adopt more generic text without device migration.

[1] https://lists.oasis-open.org/archives/virtio-comment/202309/msg00064.html

> 3) define transport specific interfaces or admin commands to access them
>
As you also envisioned, it is done using admin commands to access it.

> Does this work? It seems you refused such steps in the past.
> 
I didnât.
There must be some confusion in many emails we both exchanged, because already posted v0 has it split such as device context.

For dirty page tracking I couldnât find a solid use case without device migration, so I asked which you already replied above.

> Actually, I would like to leave 2) as it's very complicated which might not
> converge easily.
>
I will split current "device migration" section to two.
1. device management
2. device migration

Device management covers device mode, device context and dirty page tracking.
Device migration refers to device management section.

We can omit the dirty page tracking commands for a moment and first close on the device mode and device context as first step.
Since it is already part of v0 and it is needed, I will keep it in subsequent v1 but moved to device management section.

Michael,
Are you ok with this approach to step forward?