RE: [virtio-dev] [PATCH v2] virtio: Improve queue_reset polarity to match to default reset state

RE: [virtio-dev] [PATCH v2] virtio: Improve queue_reset polarity to match to default reset state

[Parav Pandit]

> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> Behalf Of Michael S. Tsirkin
> On Wed, Apr 27, 2022 at 01:25:59PM +0300, Parav Pandit wrote:
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> 
> Parav, spec comments need to be posted to virtio-comment please.
> 
I missed it, you said previously too.
Added now starting this email and v3.


> >  The device MUST reset the queue when 1 is written to
> > \field{queue_reset}, and -present a 1 in \field{queue_reset} after the
> > queue has been reset, until the
> > +present 0 in \field{queue_reset} after the queue has been reset,
> 
> ... ok
> 
> > until the
> >  driver re-enables the queue via \field{queue_enable} or the device is
> reset.
> 
> this part is just confusing. neither reset nor queue_enable will set
> queue_reset.
> just drop it?
> 
Yeah.
I took Cornelia's suggested draft and rewrote the device and driver side description.

> > +\field{queue_reset} to reset the queue, driver MUST verify that the
> > +queue has been reset by reading back \field{queue_reset} until device
> returns a value of 0.
> > +Device continue
> 
> continues
> 
> > to report
> 
> we say present elsewhere, let's be consistent
> 
> > value of 1 for the \field{queue_reset} until device finishes
> > +the queue reset request.
> 
> I'd just say "until after queue reset" consistent with what we say elsewhere.
> 
> > When the device completes the queue reset, \field{queue_reset}
> > +and \field{queue_enable} set to zero
> 
> are set to 0
> 
> >, indicating
> > +that specified queue is ready to be enabled again. The driver MAY
> > +re-enable the queue by writing 1 to
> 
> the part describing how the device works should be moved to the device
> section and be more specific with MUST/MAY.
> 
> > +\field{queue_enable} after ensuring that other virtqueue fields have
> >  been set up correctly. The driver MAY set driver-writeable queue
> > configuration  values to different values than those that were used before
> the queue reset.
> >  (see \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue
> Reset}).
> > @@ -2015,7 +2018,7 @@ \subsection{MMIO Device Register
> > Layout}\label{sec:Virtio Transport Options / Vi
> 
> same comments below.
> 

All above comments are taken care now with Cornelia's wording for your input and by correctly updating device side section now.
Sending v3.
Thanks.

[virtio-comment] RE: [virtio-dev] [PATCH v2] virtio: Improve queue_reset polarity to match to default reset state

[Cornelia Huck]

On Thu, Apr 28 2022, Parav Pandit <parav@nvidia.com> wrote:

> All above comments are taken care now with Cornelia's wording for your input and by correctly updating device side section now.
> Sending v3.

Honestly, I think it's a bit early for sending a v3 already, since it
seems we've not reached complete agreement yet what this should look
like in the end, and what we can/should do for 1.2 and what should be
deferred for 1.3. At least, it's about as clear as mud to me. Maybe
someone can summarize?


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/

RE: [virtio-dev] [PATCH v2] virtio: Improve queue_reset polarity to match to default reset state

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, April 28, 2022 3:33 AM
> 
> On Thu, Apr 28 2022, Parav Pandit <parav@nvidia.com> wrote:
> 
> > All above comments are taken care now with Cornelia's wording for your
> input and by correctly updating device side section now.
> > Sending v3.
> 
> Honestly, I think it's a bit early for sending a v3 already, since it seems we've
> not reached complete agreement yet what this should look like in the end,
> and what we can/should do for 1.2 and what should be deferred for 1.3. At
> least, it's about as clear as mud to me. Maybe someone can summarize?

Summary:
1. Michel suggested to continue to keep queue_reset register with the proposed fixes of v3
2. Jason is ok with the use cases that we see on hand are addressed with this register fix
3. Xuan's comments are addressed already in v2.
4. Comments posted from you, Michael and Jason are taken care in v3.
Waiting for reviews of v3 from Xuan, Jason, Michael for 1.2 merge.
5. github issue is up to date

I derive that we should get the fixes in 1.2.
Any complex advancement for other use cases is likely in 1.3.

Michael,
Please correct me if above is not accurate.
Did I miss anything for MMIO in v3?