OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.

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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]