OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

å 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

          /* 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.

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

I agree.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]