RE: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Tuesday, September 12, 2023 12:59 PM
> 
> On 9/12/2023 2:49 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Tuesday, September 12, 2023 12:08 PM
> >>
> >> On 9/12/2023 1:51 PM, Parav Pandit wrote:
> >>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >>>> Sent: Tuesday, September 12, 2023 9:19 AM
> >>>>
> >>>> On 9/11/2023 7:50 PM, Parav Pandit wrote:
> >>>>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >>>>>> Sent: Monday, September 11, 2023 3:03 PM By the way, do you see
> >>>>>> anything we need to improve in this series?
> >>>>> Admin commands for passthrough devices of [1] is comprehensive
> >>>>> proposal
> >>>> covering all the aspects.
> >>>>> To me [1] is superset work that covers all needed functionality
> >>>>> and downtime
> >>>> aspects.
> >>>>> I plan to improve [1] with v1 this week by extending device
> >>>>> context and
> >>>> addressing other review comments.
> >>>>> [1]
> >>>>> https://lists.oasis-open.org/archives/virtio-comment/202309/msg000
> >>>>> 61
> >>>>> .h
> >>>>> tml
> >>>> I am not sure, we have discussed a lot about the potential issues
> >>>> in the treads. I guess we should resolve them first. E.g., nested use cases.
> >>> You are using nesting use case as the _only_ use case and attempt to
> >>> steer
> >> using that.
> >>> Not right.
> >>>
> >>> If you want to discuss, then lets have both the use cases, attempt
> >>> to converge
> >> and if we can its really good.
> >>> If we cannot, both requirements should be handled differently.
> >> Isn't nested a clear use case that should be supported?
> > Most users who care for running real applications and real performance, have
> not asked for nesting.
> > It is not mandatory case; it may be required for some users.
> > I donât know who needs M level nesting and how cpu also support its
> acceleration etc to run some reasonable workload.
> Nested is a common use case and it is mandatory.
Maybe it is common case for the users you interact with, it is required for some complicated mode.
How many level of nesting 10, 2, 100?

I donât see a point of debating that "nesting is the only case and mediation is the only way" to do device migration.

As I repeatedly acknowledged, 
We are open to converge on doing administration commands that can work for passthrough and nested way.

I just donât see how nested solution can work without any mediation, as everything you do touches device reset and FLR flow and it practically breaks the PCI specification with these side band registers and faking device reset and FLR when asked.
This is the primary reason; I am less inclined to go the in-band method.
Until now, no one technically explained how it can even work on question from yesterday.

And if there is one, please explain, I am very interested to learn, how is this done without hacks where device reset by guest _actually_ reset the underlying member device while the dirty page tracking is also ongoing.

So, my humble request is, try to work towards co-existing both the methods if possible, rather than doing either or mode.