From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Parav Pandit <parav@nvidia.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>
Subject: Re: [virtio-dev] queue_reset register polarity to improve
Date: Tue, 26 Apr 2022 10:26:18 -0400 [thread overview]
Message-ID: <20220426102537-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1650785333.6800807-1-xuanzhuo@linux.alibaba.com>
On Sun, Apr 24, 2022 at 03:28:53PM +0800, Xuan Zhuo wrote:
> On Sun, 24 Apr 2022 00:49:19 +0000, Parav Pandit <parav@nvidia.com> wrote:
> > Hi,
> >
> > A recently defined queue_reset register has a little weird definition that we should improve.
> > When driver initiate queue reset, it writes queue_reset = 1.
> > When device is busy resetting the queue, on this driver request, it is expected to return queue_reset=0.
> > Once queue reset is completed it is expected to return queue_reset = 1.
> > (Polarity changed twice to same value as what was driver set). See more below.
> >
> > So state wise,
> > # q_enable, q_reset represents :
> > a) 0,0 -> device init time value
> > b) 1,0 -> vq is enabled and working
> > c) 1,1 -> vq is enabled, driver initiated reset
> > d) 1,0 -> vq is enabled, but device is busy doing the reset (conflicting definition with above #b )
> > e) 0,1 -> vq reset is complete in the device and VQ is now disabled (again conflict with #a above )
> >
> > Instead, I think we should have below better, consistent definition, no matter how queue reset occurs (init time or later).
> >
> > q_enable, q_reset
> > A) 0, 0 -> default, device init time
> > B) 1, 0 -> driver has enabled vq
> > C) 1, 1 -> driver started q reset
> > D) 1, 1 -> q_reset stays 1 until device is busy resetting vq (communicating that its working on resetting, consistent with #C)
> > E) 0, 0 -> q_reset by device is completed, q got disabled (now matches the state same as device init time #A)
>
> Seems to me to be two different designs, I don't see any particular value in the
> conflict mentioned here, and under what circumstances would it cause any
> trouble?
>
> The design here is similar to many scenarios, such as device reset.
Hmm. with device reset we have a reverse polarity:
The driver SHOULD consider a driver-initiated reset complete when it
reads \field{device status} as 0.
in what sense is the current design similar?
> So if you want to change to your design, I want to know if there are other
> reasons.
>
> Thanks.
>
> >
> > Parav
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2022-04-26 14:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-24 0:49 [virtio-dev] queue_reset register polarity to improve Parav Pandit
2022-04-24 6:46 ` [virtio-dev] " Michael S. Tsirkin
2022-04-24 7:01 ` Jason Wang
2022-04-25 13:43 ` Michael S. Tsirkin
2022-04-25 10:06 ` [virtio-dev] " Parav Pandit
2022-04-25 13:00 ` [virtio-dev] " Michael S. Tsirkin
2022-04-25 11:42 ` Cornelia Huck
2022-04-25 12:01 ` Parav Pandit
2022-04-25 13:42 ` Michael S. Tsirkin
2022-04-25 14:56 ` Parav Pandit
2022-04-25 17:32 ` Michael S. Tsirkin
2022-04-24 7:28 ` [virtio-dev] " Xuan Zhuo
2022-04-26 8:48 ` Stefan Hajnoczi
2022-04-26 8:59 ` Xuan Zhuo
2022-04-26 9:52 ` Michael S. Tsirkin
2022-04-26 9:55 ` Xuan Zhuo
2022-04-26 11:07 ` Parav Pandit
2022-04-26 12:00 ` Parav Pandit
2022-04-27 8:28 ` Xuan Zhuo
2022-04-27 20:29 ` Michael S. Tsirkin
2022-04-27 23:52 ` Parav Pandit
2022-04-26 14:26 ` Michael S. Tsirkin [this message]
2022-04-27 8:50 ` Xuan Zhuo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220426102537-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.