Re: [virtio-comment] Re: [PATCH 0/2] Selective queue enabling

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

On Tue, Jun 13, 2023 at 07:00:02PM +0000, Parav Pandit wrote:
> 
> > From: Eugenio Perez Martin <eperezma@redhat.com>
> > Sent: Tuesday, June 13, 2023 6:13 AM
> 
> > > - enable all queues before DRIVER_OK
> > > - reset all data queues before DRIVER_OK
> > > - DRIVER_OK
> > > - CVQ commands
> > > - re-enable data queues
> > >
> > >
> > > No?
> > >
> > 
> > If it is valid to write to queue_reset before DRIVER_OK, then sure. I asked for
> > that in the past at https://lists.oasis-open.org/archives/virtio-
> > dev/202305/msg00329.html
> > .
> 
> Before DRIVER_OK stage, queue_enable is already available so why to use queue reset?
> They have duplicate functionality, hence there is no motivation to support queue_reset before DRIVER_OK stage?

I do not get how.  Let's make sure we are talking about the same thing.
This is what I am saying:

Start operating:

- program queue address, size
- queue_enable

Now we change our mind about queue size or address. So:

- queue_reset
- program another queue address, size

Finally we are decided, let's start operating:

- DRIVER_OK


I don't see how it's possible with just queue_enable.


> 
> It is not explicitly mentioned in the spec that one can setup the queue using queue reset instead of queue enable.
> As Jason mentioned it is implementation specific, one device supports it and one doesn't.
> Hence, it will break on those devices which doesnt support it.
> 

Setup? No, and spec explicitly says to setup one has to use
queue_enable. But this is not what we discussed with Stefano here.

> Therefore, I would like to add it to the spec.
> "queue_reset register MUST be accessed by the driver only after device has reached the DRIVER_OK stage."

I don't think we can add MUST requirements after the proposal is
in the released spec. If device has stricter requirements than the
spec then it's not compliant.





> > 
> > >
> > >
> > > > --
> > > > MST
> > >
> > >
> > > 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/