RE: [virtio-comment] RE: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Monday, May 15, 2023 1:12 AM
> 
> å 2023/5/11 22:31, Parav Pandit åé:
> >> From: Jason Wang <jasowang@redhat.com>
> >> Sent: Thursday, May 11, 2023 3:17 AM
> >>> a configq/cmdq discussion is for new features for PF, VF, and
> >>> SF/SIOV devices to work in _non_ backward compatible way, because
> >>> for new features there is no such thing as backward compatibility
> >>> between guest driver and the device.
> >> Ok, so what command did configq/cmdq have?
> >> I thought it was similar to transport virtqueue, but it looks more like a
> control virtqueue here.
> > Yes, it is more like a cvq to do device attributes discovery and configuration.
> > Just that its generic enough.
> > For example
> > creating VQ that spans multiple physical addresses.
> > Discovery and enabling new device attributes which are rarely accessed or
> accessed during device init/cleanup time.
> >
> > The fundamental difference between cfgvq to tvq is:
> > Cfgvq is between the member virtio device and its driver.
> > Tvq=aq is on group owner of the virtio device.
> >
> >>>>> Compatibility is coming at a cost which is not scaling.
> >>>>> If you attempt to scale, it breaks the future path forward to go
> >>>>> without
> >> mediation.
> >>>>>>> So eve growing these fields and optionally placement on configq
> >>>>>>> doesn't really help and device builder to build it efficiently
> >>>>>>> (without much predictability).
> >>>>>> Config queue is not the only choice, we have a lot of other
> >>>>>> choices (for example PASID may help to reduce the on-chip resources).
> >>>>>>
> >>>>> PASID is for process isolation security construct, it is not for
> transportation.
> >>>> I meant with PASID you don't even need a BAR.
> >>>>
> >>> Not sure I fully understand, but my guess is, this is coming from
> >>> mediation thought process.
> >> Not actually. I meant, for example without PASID, for modern devices,
> >> the common cfg structure must be placed on a BAR through MMIO.
> >>
> >> But with the help of PASID, it could stay in the memory and the
> >> device can fetch it via DMA. The help to reduce the resources for registers.
> >>
> > Yes, it can stay in memory and device can fetch via DMA using a VQ using its
> own q from guest driver.
> > Why does it need PASID?
> 
> 
> Let me clarify my understanding.
> 
> If we want a per VF virtqueue that is used by the hypervisor. We need PASID.
> Otherwise not.

Yes, we are on same page, only when such device is mediated by hypervisor.
Without mediation PASID is not required.