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

["Michael S. Tsirkin" <mst@redhat.com>]

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.

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.


> [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.