From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH v1] virtio-mmio: Specify wait needed in driver during reset From: Srivatsa Vaddagiri Date: Mon, 26 Jul 2021 14:17:08 +0000 Message-ID: References: <87h7gh5od5.fsf@redhat.com> <87eebl5msn.fsf@redhat.com>,<20210726091851-mutt-send-email-mst@kernel.org> In-Reply-To: <20210726091851-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BY5PR02MB7073036306A91FEF52CCC5FBF9E89BY5PR02MB7073namp_" To: "Michael S. Tsirkin" , Cornelia Huck Cc: "jasowang@redhat.com" , "virtio-dev@lists.oasis-open.org" , Trilok Soni , Pratik Patel List-ID: --_000_BY5PR02MB7073036306A91FEF52CCC5FBF9E89BY5PR02MB7073namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > On Mon, Jul 26, 2021 at 01:36:56PM +0200, Cornelia Huck wrote: > > On Mon, Jul 26 2021, Srivatsa Vaddagiri wro= te: > > > > >> > +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 probabl= y > > 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. --_000_BY5PR02MB7073036306A91FEF52CCC5FBF9E89BY5PR02MB7073namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> 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 drive= r 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 r= esult. 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 p= ut in some text in spec to that
> > > effect?
> >
> > Not sure whether it is needed (do other= s have an opinion?), but probably
> > not.
>
> What about resets before FEATURES_OK? How ar= e these handled?

From device perspective, it's reset logic will al= ways be same, independent of
when reset was performed by driver (before or aft= er feature negotiation). A
driver that does not wait for reset completion wi= ll see undefined behavior after
reset until it discovers that feature negotiation= has failed?

- vatsa

---

Qualcomm Innovation Center, Inc. is submitting th= e attached "feedback" as a
non-member to the virtio-dev mailing list for co= nsideration and inclusion.


--_000_BY5PR02MB7073036306A91FEF52CCC5FBF9E89BY5PR02MB7073namp_--