RE: [virtio-dev] RE: [PATCH v5 0/7] Introduce device group and device management

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, July 5, 2022 10:54 PM
> 
> On Tue, Jul 5, 2022 at 11:11 PM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, July 5, 2022 9:57 AM
> > >
> > > On Wed, Apr 27, 2022 at 01:58:17AM +0300, Max Gurtovoy wrote:
> > > > Hi,
> > > > A device group definition will help extending the virtio
> > > > specefication for various future features that require a notion of
> > > > grouping devices together or managing devices inside a group. A
> > > > device group include one or
> > > more virtio devices.
> > > > For now, only support for type 1 device group was added.
> > >
> > > How about posting a new version? I frankly think between the
> > > hardware hack I proposed and the new admin queue transport proposal,
> > > we do not need to work hard to save on writeable registers and so
> > > for starters at least we can just use feature bits instead of the query
> capability command.
> >
> > Reader and writer via different channel is really a hack.
> > It still doesn't help to have efficient hw.
> 
> So having 2 or 4 32bit registers just for PF doesn't seem expensive to me.
> Another 64/128 bit should be sufficient for the future 5 or 10 years.
> 
> >
> > What is the technical reason to use feature bits which has strong
> relationships with device initialization sequence?
> 
> Using admin virtqueue may suffer from bootstrapping issues. Especially the
> features that may affect the vring itself.
> 
> E.g we may want to have
> 
> 1) new vring layouts (similar to packed virtqueue)
> 2) new way to coalesce/suppress notification (similar to event index)
> 3) new way to notify the device (similar to notification data)
> 
> Those features can't be negotiated by admin virtqueue.
Sure. There is no motivation to negotiate them via AQ either.
My ask is below.
a. functionality done over AQ is negotiated via AQ, things that has no relation to device init sequence
b. functionality of the device that has strong relation to device init sequence stays as today via feature bits.
For example, the cases you described above.

> 
> Thanks
> 
> > The proposed bits are AQ functionality bits and not per_say device feature
> bits?
> >
> > This enables to build device in lot more flexible (and frankly simple way).
> > Looking at sw guest driver being simple to use existing limited 64-bits is just
> one part of it.
> >
> > And when AQ exists, most of the plumbing comes for free.
> > So I fail to see the simplicity benefit of overloading feature bits for things
> that has no relation to device init sequence.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >