Re: [virtio-dev] Re: [PATCH v1] virtio-mmio: Specify wait needed in driver during reset

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Jul 27 2021, Srivatsa Vaddagiri <svaddagi@qti.qualcomm.com> wrote:

>> > > What about resets before FEATURES_OK? How are these handled?
>> >
>> > From device perspective, it's reset logic will always be same, independent of
>> > when reset was performed by driver (before or after feature negotiation). A
>> > driver that does not wait for reset completion will see undefined behavior
>> > after
>> > reset until it discovers that feature negotiation has failed?
>>
>> Hmm. that doesn't sound too good. Makes using
>> feature negotiation for this kind of useless ...
>> Device can actually detect a read from status, right?
>> Maybe if it sees status was not read it can just
>> stay in reset state and not exit it?
>
> Thinking on those lines, I am wondering if we can avoid the feature bit
> all together based on that logic.
>
> 1) Driver writes 0 to status register - device initiates reset sequence
> 2) Driver reads status - return 0x40 (VIRTIO_CONFIG_S_NEEDS_RESET)
>    if reset sequence is in progress, otherwise return 0

I don't think we can have the device return NEEDS_RESET in that case;
that status is supposed to indicate "that the device has experienced an
error from which it canât recover" -- which is not the case here,
especially since the driver has already initiated a reset.

> 3) Driver writes status (ACKNOWLEDGE Bit) - if this happened before reset
>    sequence completed and before we returned 0 for status read, then reject
>    further initialization by setting VIRTIO_CONFIG_S_NEEDS_RESET (until next
>    reset that is)
>
> This should let device detect if we have a driver polling on reset completion or
> not?