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 3:47 PM
> 
> On 9/12/2023 5:28 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Tuesday, September 12, 2023 2:36 PM If you want AQ used for LM,
> >> it should support nested anyway, don't break user logic.
> > You ignored the other part of my question when you asked above.
> > i.e. a PCI transport do not allow such weird bifurcation.
> I failed to process your comment. 

> Do you mean the registers don't support nested?
No. I mean registers access should support device reset flow and FLR flow.

> >>

> >> This (my)series can support nested.
> > Maybe it does, with hacking the device reset and FLR sequence, without dirty
> tracking, without P2P support, without passthrough mode.
> > All these requirements are not addressed.
> >
> > If you intent to cover both requirements, lets work towards it to see
> > if it can converge, if there are technical challenges, then there is no point in
> pushing to claim that in-band VF with mediation is the only way to move
> forward.
> Why do you need P2P? 
I answered this before few hours back.

> Why FLR and reset are concerned? 
Because they must work.
> Why do you think dirty page tracking is not supported?
Because you wrote in cover letter " Future work: dirty page tracking and in-flight descriptors."
And you repeatedly resisted administration commands. I donât see how above two can be done efficiently without administration commands.
And if one is going to use administration command in future for above two, there is no point of doing current series over registers.
I donât see how and administration queue can work after device is suspended, and after FLR how dirty page tracking can continue.

All these aspects are covered in [1] that can be extended for nesting if needed with side car VF.

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