On 211217 1625, Philippe Mathieu-Daudé wrote: > On 12/17/21 15:30, Alexander Bulekov wrote: > > On 211217 1458, Philippe Mathieu-Daudé wrote: > >> On 12/17/21 04:08, Alexander Bulekov wrote: > >>> Here's my shot at fixing dma-reentracy issues. This patch adds a flag to > >>> the DeviceState, which is set/checked when we call an accessor > >>> associated with the device's IO MRs. > >> > >> Your approach is exactly what Gerd suggested: > >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg831437.html > > > > Yes - my bad for not searching my mail more carefully. > > Well it is not "exactly" the same, but almost. > > >> > >>> The problem, in short, as I understand it: For the vast majority of > >>> cases, we want to prevent a device from accessing it's own PIO/MMIO > >>> regions over DMA. > >>> > >>> This patch/solution is based on some assumptions: > >>> 1. DMA accesses that hit mmio regions are only dangerous if they end up > >>> interacting with memory-regions belonging to the device initiating the > >>> DMA. > >>> Not dangerous: sdhci_pio->dma_write->e1000_mmio > >>> Dangerous: sdhci_pio->dma_write->sdhci_mmio > >> > >> It doesn't have to be dangerous, see Paolo's example which > >> invalidated my previous attempt and forced me to write 24 > >> patches in multiples series to keep the "niche" cases working: > >> https://www.mail-archive.com/qemu-block@nongnu.org/msg72939.html > > > > I don't understand what IO accesses this decodes to. This is loading a > > picture into VRAM? > > I'd say "loading a picture into VRAM via the DMA" but am not sure :) > > This link is helpful: > http://petesqbsite.com/sections/tutorials/tutorials/peekpoke.txt >
https://github.com/microsoft/GW-BASIC/blob/edf82c2ebf6bfe099c2054e0ae125c3efe5769c4/GIO86.ASM#L333 AFAICT this would just do repeated MMIO writes to VRAM - no DMA involved? Maybe there is some way to log when a device performs a DMA access to it's own IO regions, so that we could identify these niche cases? We would still need a way to actually trigger that behavior...
