From: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
Jason Wang <jasowang@redhat.com>,
virtio-dev@lists.oasis-open.org, tsoni@quicinc.com,
pratikp@quicinc.com
Subject: Re: [PATCH v2] virtio-mmio: Specify wait needed in driver during reset
Date: Mon, 16 Aug 2021 11:52:33 +0530 [thread overview]
Message-ID: <20210816062233.GC5604@quicinc.com> (raw)
In-Reply-To: <20210816010725-mutt-send-email-mst@kernel.org>
* Michael S. Tsirkin <mst@redhat.com> [2021-08-16 01:30:57]:
> > +After writing 0 to \field{Status}, which triggers a reset of device, the driver MUST wait for a read of
> > +\field{Status} to return 0 before proceeding with the remaining steps of initializing the device.
>
> I know you copied this from pci but looking at PCI now, I think
> this is not great there either.
>
> 1. This is IMHO too opaque in that we did not say driver should read.
>
> E.g. after writing 0 to Status and before reading any fields, the driver
> MUST read Status and wait for a read etc.
>
> also would not just a read be sufficient? Is there a case for device to return any value
> other than 0 to signal "reset in progress"?
Not sure I follow you here. We need some means for device to indicate its reset
operation is complete - non-zero value of Status would indicate reset is still
in progress while zero value would indicate reset is complete?
> 2. what if device encounters an error and sets
> NEED_RESET meanwhile? waiting for a reset will then deadlock ...
> I know, it's problematic like this in PCI too.
Hmm a reset itself having failed - not sure if another reset will clear things
up better. I guess device could attempt another reset by itself, but may give up
after couple of attempts by indicating NEED_RESET, at which point not sure if
another driver initiated reset will make a difference. At the minimum, the
guidance for drivers here would be to block until reset is completed (indicated
by Status returning 0) or device encountering some failure (NEED_RESET)? When
NEED_RESET is seen, should the spec prescribe driver to attempt reset again?
> Further what will device return after reset was written but
> before it completed? I think it is better to specify that
> rather than rely on any non-0 value meaning "wait for reset".
Yes agree, we should have a specific status bit to indicate "reset in progress"
> For pci maybe make it a SHOULD ...
Do you mean pci driver SHOULD wait until this new status bit (RESET_IN_PROGRESS)
is cleared?
- vatsa
---
Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a
non-member to the virtio-dev mailing list for consideration and inclusion.
next prev parent reply other threads:[~2021-08-16 6:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 14:53 [PATCH v2] virtio-mmio: Specify wait needed in driver during reset Srivatsa Vaddagiri
2021-08-16 2:10 ` Jason Wang
2021-08-16 4:57 ` Srivatsa Vaddagiri
2021-08-16 5:07 ` Michael S. Tsirkin
2021-08-16 5:30 ` Michael S. Tsirkin
2021-08-16 6:22 ` Srivatsa Vaddagiri [this message]
2021-08-20 4:01 ` Jason Wang
2021-08-17 15:26 ` [virtio-dev] " Cornelia Huck
2021-08-18 2:39 ` Jason Wang
2021-08-18 6:34 ` [virtio-dev] " Cornelia Huck
2021-08-20 3:48 ` Jason Wang
2021-08-20 11:18 ` Michael S. Tsirkin
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=20210816062233.GC5604@quicinc.com \
--to=quic_svaddagi@quicinc.com \
--cc=cohuck@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=pratikp@quicinc.com \
--cc=tsoni@quicinc.com \
--cc=virtio-dev@lists.oasis-open.org \
/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.