> On Mon, Jul 26, 2021 at 01:36:56PM +0200, Cornelia Huck wrote: > > On Mon, Jul 26 2021, Srivatsa Vaddagiri <[email protected]> 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?
>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? - vatsa --- Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a non-member to the virtio-dev mailing list for consideration and inclusion.
