RE: [PATCH v5 2/7] Introduce admin command set

[Parav Pandit <parav@nvidia.com>]

Hi Michael,

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, May 15, 2022 11:24 AM

[..]

> > +\subsection{VIRTIO ADMIN DEVICE CAPS ACCEPT
> command}\label{sec:Basic
> > +Facilities of a Virtio Device / Admin command set / VIRTIO ADMIN
> > +DEVICE CAPS ACCEPT command}
> > +
> > +The VIRTIO_ADMIN_DEVICE_CAPS_ACCEPT command is used by the
> driver to acknowledge those admin capabilities it understands and wishes to
> use.
> 
> 
> ok so we have a protocol here, kind of like feature negotiation. Please write
> its description.
> e.g. is it ok to change accepted caps? when? can device change its caps etc
> etc etc.
> 
> Avoiding this kind of spec work is exactly why me and jason keep telling you
> to consider just using features instead. Add a 64 bit admin features field to
> the PCI transport and be done with it. CCW and MMIO already have feature
> selector so it's trivial to add feature bits.
> 
As we begin to scale with the device, adding more and more registers like this demands more on-device real estate to comply to the PCI standards.

And therefore, things are queried/accessed rare or occasionally, are better accessed via a queue interface.

One can argue that admin VQ is proposed only for the mgmt. functions so having this cfg register for PF is enough.

However, AQ may find some usage in the VF/SF themselves down the road.
Hence, keeping the cap exchange transport this way is more optimal.

Max has called out this AQ rationale in 4 or 5 points in the cover letter.