OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Mon, Jul 26 2021, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Jul 26, 2021 at 01:36:56PM +0200, Cornelia Huck wrote:
>> On Mon, Jul 26 2021, Srivatsa Vaddagiri <svaddagi@qti.qualcomm.com> wrote:
>> 
>> >> > +indicated by a read of \field{Status} returning 0. Such a device MUST also
>> >> > fail to accept
>> >> > +FEATURES_OK bit if driver does not negotiate VIRTIO_F_MMIO_RESET_WAIT.
>> >>
>> >> So, this basically means that an older driver that does not know the new
>> >> feature bit will not work with devices offering this bit, even if it did
>> >> poll? This seems acceptable, I just wanted to spell it out.
>> >
>> > Yes I believe that's the desired result. Device has no way to know if driver
>> > will poll for reset completion or not unless it accepts the feature.
>> > Are you suggesting we explicitly put in some text in spec to that
>> > effect?
>> 
>> Not sure whether it is needed (do others have an opinion?), but probably
>> not.
>
> What about resets before FEATURES_OK? How are these handled?

I'd say that neither driver nor device can assume anything. I.e. if the
driver writes 0 to status, it won't know whether it should poll or not
(polling would be the safe bet), and the device simply cannot know
whether the driver will wait with the next operation or continue
immediately.

Do we want to spell that out?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]