Re: [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 02, 2021 at 07:03:11PM +0300, Max Gurtovoy wrote:
> There is no much bits left in the generic feature field for all the features
> we would like to add.
> I mentioned only 5-6 in the above example and it will bring us to bit 46
> already.
> 
> please think of 5-10 years from today.
> 

IIUC nothing prevents adding more once we exhaust 64 bits. IMHO it's actually
pretty important to make sure the feature negotiation works well
and covers relevant usecases. If we have limitations preventing that
I'd like to at least try to fix that not replacing feature negotiation with
something else.

> 
> > 
> > What actually makes sense to use the admin vq is also worth further
> > discussion.
> > 
> > > 
> > > > > > > > > As virtio evolves beyond the para-virt/sw-emulated world, it's mandatory
> > > > > > > > > for the specification to become flexible and allow a wider feature set.
> > > > > > > > > The corrent ctrl virtq that is defined for some of the virtio devices is
> > > > > > > > > device specific and wasn't designed to be a generic virtq for
> > > > > > > > > admininistration.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> > > > > > > > Lots of things on this list seem to make sense when
> > > > > > > > done from PF and affecting a VF.
> > > > > > > > I think from this POV the generic structure should include
> > > > > > > > a way to address one device from another.
> > > > > > > This will be defined per command.
> > > > > > > 
> > > > > > > For example, funcion_id will be given as command data.
> > > > > > Why? Sounds like a generic thing to me.
> > > > > Generic to a command that handles virtualization management.
> > > > It could be that mixing up virtualization management and arbitrary
> > > > other management commands in the same interface is a mistake.
> > > It's not a mistake.
> > > 
> > > This is the right design.
> > Well, we're clearly not all in agreement what the "right design"
> > is. Figuring that out is the whole point of this discussion.
> 
> I suggested a solid infrastructure for adding any feature easily in the
> future without having half a year waste on debates.

Well we don't really normally waste time on debating adding feature bits.
We do that a lot without a lot of fuss.

-- 
MST