Re: [virtio-comment] RE: [PATCH 1/2] virtio: introduce selective queue enabling

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

On Thu, Jun 08, 2023 at 01:53:32PM +0200, Eugenio Perez Martin wrote:
> On Tue, Jun 6, 2023 at 9:25 PM Parav Pandit <parav@nvidia.com> wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, June 6, 2023 3:20 PM
> > > >
> > > > Can you please highlight, current spec normative which indicates that
> > > > all queues must be enabled before DRIVER_OK and more queues cannot be
> > > > enabled after DRIVER_OK?
> > >
> > >
> > > This one:
> > > \drivernormative{\subsection}{Device Initialization}{General Initialization And
> > > Device Operation / Device Initialization}
> > >
> > > it does not say "all queues" if you want to split hairs but I think assuming it's
> > > safe to enable queues later is dangerous.
> > >
> > Yes, I have read it few times and every time I concluded that:
> > it does not say that it must be done before DRIVER_OK and cannot be done after DRIVER_OK.
> >
> 
> I also read it this way to be honest.

You have been doing spec lawyering for too long, take a step
back, take a walk, then look at it from common sense POV.


Well spec says: you MUST follow this order:
- A
- B
- C

can one conclude that if C triggers then B already happened?

I would conclude yes.



and just because it does not say *and do not do it in any other
order* you are saying
- A
- C
- B

is also allowed?

MUST follow this rule to me means "and do not violate this rule".




> From a POV, to allow it if a
> device does not handle it could be considered a fix, rather than an
> addition.

I think vhost user at least is started at DRIVER_OK and at
that point it looks at # of enabled Qs and allocates a bunch
of arrays to match.


> I'm assuming we need to modify the standard just because it was not
> explicitly allowed. To explicitly allow it before DRIVER_OK was not
> needed because it was already widespread.
> 
> It would be great for me if we agree the device must support it, but
> maybe it is just too late for that.
> 
> Thanks!
> 
> > > E.g. vhost user backends tend to assume no new queues appear after
> > > DRIVER_OK.
> >
> > This backend implementation can be improved without introducing new bits on the guest side.
> > Q reset is already a second example that demonstrates that queues will be disabled/enabled after DRIVER_OK.
> >
> > And for PCI transport, PCI device and driver do not restrict queue_enable access after DRIVER_OK.
> >
> > This publicly archived list offers a means to provide input to the
> > OASIS Virtual I/O Device (VIRTIO) TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> > List help: virtio-comment-help@lists.oasis-open.org
> > List archive: https://lists.oasis-open.org/archives/virtio-comment/
> > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> > Committee: https://www.oasis-open.org/committees/virtio/
> > Join OASIS: https://www.oasis-open.org/join/
> >


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/