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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, June 20, 2022 4:54 PM
> 
> On Mon, Jun 20, 2022 at 05:19:26PM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Monday, June 20, 2022 1:04 PM
> > >
> > > Max with transport I am not talking about admin queue specifically.
> > > The point Parav made is that he wants to avoid using memory writable
> > > registers for slow path configuration, as far as possible.
> > Precisely, especially those one which doesn't have direct impact on the
> device initialization sequence.
> >
> > Please see my previous response.
> 
> Right. However
> 1. The cost is quite modest here. E.g. we have two feature selectors which
>    just wastes bits.
Today because of short proposal there are two bits. But I expect them to grow.
For example, a device capable of modifying feature bits, num_vqs will expose two more bits.
For net specific device, one might want to configure mac, mtu of the device.
LM specific capabilities, write logging capable.
List will have few more entries.

>    How bad would be to just use feature bits for now, and
>    later/separately add an interface that reduces amount of writeable mmio,
>    if deemed appropriate?
If one can think of using AQ to implement vdpa over virtio device, and having AQ on each VF, each VF will now have to have rare entries as registers.
I think we can do better.

> 2. Driver features are writeable but device features are not -
>    so why not have device features in memory?
> 

If virtio spec builds the channel to write driver features, it is more logical to use same channel to read too.