On Mon, Jul 26 2021, "Michael S. Tsirkin" <[email protected]> wrote:
> 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? 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
