> From: Zhu, Lingshan <lingshan....@intel.com> > Sent: Tuesday, September 12, 2023 3:45 PM > > On 9/12/2023 5:35 PM, Parav Pandit wrote: > > > >> From: Zhu, Lingshan <lingshan....@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.
