Weird, I see Jason's reply in the archives:
/msg08603.html">https://www.mail-archive.com/[email protected]/msg08603.html
but not the original message by Parav.
Prav, I will send an email to OASIS tech support, it's important
that communication is archived.
On Wed, Jul 06, 2022 at 10:54:08AM +0800, Jason Wang wrote:
> On Tue, Jul 5, 2022 at 11:11 PM Parav Pandit <> wrote:
> >
> >
> >
>
From: Michael S. Tsirkin <>
> >
> 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:
>
> For additional commands, e-mail:
> >
