Re: [PATCH v2] memory: prevent dma-reentracy issues

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 24 Oct 2022 at 19:46, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Thu, Oct 20, 2022 at 06:11:06PM -0400, Alexander Bulekov wrote:
> > Taking a stab at this. Here is the list of DMA APIs that appear to need
> > changes:
> > dma_memory_valid (1 usage)
> > dma_memory_rw (~5 uses)
> > dma_memory_read (~92 uses)
> > dma_memory_write (~71 uses)
> > dma_memory_set (~4 uses)
> > dma_memory_map (~18 uses)
> > dma_memory_unmap (~21 uses)
> > {ld,st}_{le,be}_{uw,l,q}_dma (~10 uses)
> > ldub_dma (does not appear to be used anywhere)
> > stb_dma (1 usage)
> > dma_buf_read (~18 uses)
> > dma_buf_write (~7 uses)
> >
> > These appear to be internal to the DMA API and probably don't need to be
> > changed:
> > dma_memory_read_relaxed (does not appear to be used anywhere)
> > dma_memory_write_relaxed (does not appear to be used anywhere)
> > dma_memory_rw_relaxed
> >
> > I don't think the sglist APIs need to be changed since we can get
> > DeviceState from the QEMUSGList.
> >
> > Does this look more-or-less right?
>
> That's along the lines of what I would expect. Interesting that
> map/unmap is also on the list; it makes sense when considering bounce
> buffers.

Not all devices that DMA do it via the dma_memory_* wrappers, of course:
some just use address_space_* functions directly. I guess maybe
we can just make the devices where we care about this problem
be more consistent about what function family they use.

-- PMM