qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 0/3] try to solve the DMA to MMIO issue


From: Jason Wang
Subject: Re: [RFC 0/3] try to solve the DMA to MMIO issue
Date: Fri, 4 Sep 2020 10:45:13 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


On 2020/9/3 下午7:19, Peter Maydell wrote:
On Thu, 3 Sep 2020 at 12:11, Li Qiang <liq3ea@gmail.com> wrote:
Peter Maydell <peter.maydell@linaro.org> 于2020年9月3日周四 下午6:53写道:
On Thu, 3 Sep 2020 at 04:55, Jason Wang <jasowang@redhat.com> wrote:
I think we still need to seek a way to address this issue completely.

How about adding a flag in MemoryRegionOps and detect the reentrancy
through that flag?
This won't catch everything. Consider this situation:
   Device A makes DMA access to device B
   Device B's write-handling causes it to raise an
    outbound qemu_irq signal
   The qemu_irq signal is connected to device A
Here mean device A is an interrupt controller?
No. Any device can have an inbound or outbound qemu_irq line.
We use them not just for actual IRQ lines but for any
situation where we need to pass an on-or-off signal from
one device to another.

This is special case I think.
It's an example of why looking purely at MMIO is not
sufficient. We should prefer to see if we can come up with
a design principle that works for all between-device
coordination before we implement something that is specific
to MMIO.


As discussed, maybe we can track the pending operations in device itself and check it in all the possible entry of device codes (irq, MMIO or what ever else). This may be easier for stable backport.

Thanks



thanks
-- PMM





reply via email to

[Prev in Thread] Current Thread [Next in Thread]