Weird, I see Jason's reply in the archives: 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 <[email protected]> wrote: > > > > > > > From: Michael S. Tsirkin <[email protected]> > > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
