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

[Jason Wang <jasowang@redhat.com>]

å 2021/8/17 äå3:51, Michael S. Tsirkin åé:
> On Tue, Aug 17, 2021 at 01:45:12PM +0800, Jason Wang wrote:
> > å 2021/8/16 äå7:48, Michael S. Tsirkin åé:
> > > On Mon, Aug 16, 2021 at 12:05:50PM +0530, Srivatsa Vaddagiri wrote:
> > > > * Michael S. Tsirkin <mst@redhat.com> [2021-08-16 01:35:46]:
> > > >
> > > > > So thinking about all this, quite early in the setup process we
> > > > > have:
> > > > >
> > > > >           /* Figure out what features the device supports. */
> > > > >           device_features = dev->config->get_features(dev);
> > > > >
> > > > >
> > > > > isn't this sufficient? this will flush out
> > > > > all writes and device can defer responding to reads
> > > > > until reset is complete.
> > > > Hmm not sure if that's possible in all MMIO devices? I think a while back Jason
> > > > felt some of the MMIO devices, their registers could act as plain DRAM for
> > > > reads, which means device can't block such reads?
> > > >
> > > > - vatsa
> > > Is it worth bothering about theoretical issues though? Jason what is
> > > your take?
> >
> > Re-read the spec, and it said
> >
> > "
> >
> > MMIO Device Register Layout
> >
> > "
> >
> > I believe plain DRAM will not behave like a register. So we don't need to
> > worry about that.
> >
> > But they are indeed devices that act as a plain DRAM for their control path,
> > which might requires new transports[1].
> >
> > Another question is that what makes PCI differ from MMIO. (E.g PCI requires
> > a re-read but MMIO doesn't)
> I don't think PCI requires a re-read either.  IIRC from that meeting, it
> was intended for a hypervisor so it does not have to block the guest:
> the guest can do something else then re-read.
> We did similar things elsewhere.


Yes, but it has implication for the device implication.


> See
> https://issues.oasis-open.org/projects/VIRTIO/issues/VIRTIO-103
> for the original proposal.
>
> In any case, I would say status register is unlikely to be in regular
> DRAM, after all write has side effects.
> So before we move on I'd like to know whether we do something as drastic
> as incrementing the version number for a theoretical or practical
> benefit.


I agree.

Thanks


> > [1] https://lkml.org/lkml/2020/9/1/255
> >
> >
> > > > ---
> > > >
> > > > Qualcomm Innovation Center, Inc. is submitting the attached "feedback" as a
> > > > non-member to the virtio-dev mailing list for consideration and inclusion.