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:45 PM
> 
> On 9/12/2023 5:35 PM, Parav Pandit wrote:
> >
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Tuesday, September 12, 2023 2:38 PM
> >> supplementary: As Jason ever pointed out: the two solution can
> >> co-exist for sure, I am implementing basic facilities, admin vq can
> >> free feel to reuse them like forwarding messages to them, and this can help
> support nested.
> > Sure. Sounds good.
> >
> > At lest two device vendors + other industry bodies including led by Intel are
> moving away from the register-based implementation in virtualization area.
> This series is self-contained, it is an register based solution. It introduces basic
> facilities, doesn't depend on others like AQ.
> > And registers that you expose are not supporting device reset and FLR
> sequence. So please add some text for that in PCI transport section about
> violation.
> > And guideline for driver on how it should not touch them to make this usable.
> > This will make the nested solution more clear.
> PCI FLR is out of this scope, for virtio you can still reset the device by writing 0.
> >
> > Do you find the administration commands we proposed in [1] useful for
> nested case?
> > If not, both will likely diverge.
> Not till now.
> >
> > We would like to avoid suspending individual VQs in the passthrough case, as
> things are controlled at the device level.
> > It also reduces driver -> device interaction for large queue count ranging from
> 1 to 32K.
> >
> > So at present I see very little overlap between the two. I will look more again
> on 9/13 if passthrough proposal can utilize anything from your series.
> It does not suspending an individual VQ, when suspend, all VQs are STOPPED.

We need to stop configuration notifications as well and shared memory update etc.