Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Wang <jasowang@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>,
	Virtio-Dev <virtio-dev@lists.oasis-open.org>,
	Trilok Soni <tsoni@quicinc.com>
Subject: [virtio-dev] Re: [PATCH v3] virtio-mmio: Specify wait needed in driver during reset
Date: Fri, 26 Nov 2021 09:35:30 +0100	[thread overview]
Message-ID: <87v90fiab1.fsf@redhat.com> (raw)
In-Reply-To: <CACGkMEun-obsMTLAGCCtKpqNxWHBKk_QC_6WywsVsFb7mfW9qw@mail.gmail.com>

On Fri, Nov 26 2021, Jason Wang <jasowang@redhat.com> wrote:

> On Fri, Nov 26, 2021 at 5:25 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>>
>> On Tue, Aug 31, 2021 at 07:27:53PM +0530, Srivatsa Vaddagiri wrote:
>> > Reset of a virtio-mmio device is initiated by writing 0 to its Status register.
>> > In case of some devices, the reset operation itself may not be completed
>> > by the time write instruction completes and hence such devices would require
>> > drivers to wait on reset operation to complete before they proceed with
>> > remaining steps of initialization.
>> >
>> > Update the specification to indicate which devices would need driver to block on
>> > reset completion.
>> >
>> > Suggested-by: Jason Wang <jasowang@redhat.com>
>> > Signed-off-by: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>
>>
>> I have been thinking about this some more.
>>
>>
>> \section{Device Reset}\label{sec:Basic Facilities of a Virtio Device / Device Reset}
>>
>> The driver may want to initiate a device reset at various times; notably,
>> it is required to do so during device initialization and device cleanup.
>>
>> The mechanism used by the driver to initiate the reset is transport specific.
>>
>> \devicenormative{\subsection}{Device Reset}{Basic Facilities of a Virtio Device / Device Reset}
>>
>> A device MUST reinitialize \field{device status} to 0 after receiving a reset.
>>
>> A device MUST NOT send notifications or interact with the queues after
>> indicating completion of the reset by reinitializing \field{device status}
>> to 0, until the driver re-initializes the device.
>>
>> \drivernormative{\subsection}{Device Reset}{Basic Facilities of a Virtio Device / Device Reset}
>>
>> The driver SHOULD consider a driver-initiated reset complete when it
>> reads \field{device status} as 0.
>
> I wonder if we need to switch to using MUST here.

I'm not quite sure what advantage s/SHOULD/MUST/ would give us here.

I don't think we want to force the driver to read back the device status
to determine success if the transport already has a different way to
signal completion. (I probably should undust my ccw reset clarification
patch...)

>> So I guess we can just fix the mmio driver to read status
>> and declare victory? Do we really need all the spec changes?
>
> Probably, but one consideration of this change is to avoid the
> breaking of existing devices. Maybe it's over engineering.

How big is the chance that we use an unfixed driver with a device that
would get it into trouble? The proposed change is pretty complex, I'd
rather avoid it if possible.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2021-11-26  8:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 13:57 [PATCH v3] virtio-mmio: Specify wait needed in driver during reset Srivatsa Vaddagiri
2021-08-31 14:45 ` Michael S. Tsirkin
2021-08-31 15:56   ` [virtio-dev] " Srivatsa Vaddagiri
2021-09-01  1:19     ` Michael S. Tsirkin
2021-09-01 13:31       ` Srivatsa Vaddagiri
2021-09-02  7:27         ` Jason Wang
     [not found] ` <20211125162349-mutt-send-email-mst@kernel.org>
     [not found]   ` <CACGkMEun-obsMTLAGCCtKpqNxWHBKk_QC_6WywsVsFb7mfW9qw@mail.gmail.com>
2021-11-26  8:35     ` Cornelia Huck [this message]
2021-11-29  2:40       ` Jason Wang

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=87v90fiab1.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=quic_svaddagi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox