From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4bJA-0007L7-DU for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:48:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4bJ4-0004iw-Vi for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:48:40 -0400 Received: from smtp2-g21.free.fr ([2a01:e0c:1:1599::11]:56237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4bJ4-0004hh-PL for qemu-devel@nongnu.org; Mon, 15 Jun 2015 16:48:34 -0400 Message-ID: <557F3943.1040300@reactos.org> Date: Mon, 15 Jun 2015 22:44:51 +0200 From: =?ISO-8859-15?Q?Herv=E9_Poussineau?= MIME-Version: 1.0 References: <1434054631-32241-1-git-send-email-hpoussin@reactos.org> <20150611233006.GA14284@aurel32.net> In-Reply-To: <20150611233006.GA14284@aurel32.net> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] dma/rc4030: do multiple calls to address_space_rw when doing DMA transfers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Leon Alrae , Peter Maydell , Paolo Bonzini Hi Aurelien, Le 12/06/2015 01:30, Aurelien Jarno a =E9crit : > On 2015-06-11 22:30, Herv=E9 Poussineau wrote: >> This workarounds a bug in memory management. >> >> To reproduce the problem, try to start the Windows NT 4.0/MIPS install= er. >> After loading some files, you should see a screen saying >> "To set up Windows NT now, press ENTER." >> However, you're welcomed with an IRQL_NOT_LESS_OR_EQUAL bugcheck or an >> Unknown Hard Error c0000221. >> >> Signed-off-by: Herv=E9 Poussineau >> --- >> hw/dma/rc4030.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/hw/dma/rc4030.c b/hw/dma/rc4030.c >> index 3efa6de..d265d6c 100644 >> --- a/hw/dma/rc4030.c >> +++ b/hw/dma/rc4030.c >> @@ -681,6 +681,7 @@ static void rc4030_do_dma(void *opaque, int n, uin= t8_t *buf, int len, int is_wri >> rc4030State *s =3D opaque; >> hwaddr dma_addr; >> int dev_to_mem; >> + int i; >> >> s->dma_regs[n][DMA_REG_ENABLE] &=3D ~(DMA_FLAG_TC_INTR | DMA_FLA= G_MEM_INTR | DMA_FLAG_ADDR_INTR); >> >> @@ -699,8 +700,22 @@ static void rc4030_do_dma(void *opaque, int n, ui= nt8_t *buf, int len, int is_wri >> dma_addr =3D s->dma_regs[n][DMA_REG_ADDRESS]; >> >> /* Read/write data at right place */ >> +#if 1 /* workaround for a bug in memory management */ >> + for (i =3D 0; i < len; ) { >> + int ncpy =3D DMA_PAGESIZE - (dma_addr & (DMA_PAGESIZE - 1)); >> + if (ncpy > len - i) { >> + ncpy =3D len - i; >> + } >> + address_space_rw(&s->dma_as, dma_addr, MEMTXATTRS_UNSPECIFIED= , >> + buf + i, ncpy, is_write); >> + >> + dma_addr +=3D ncpy; >> + i +=3D ncpy; >> + } >> +#else >> address_space_rw(&s->dma_as, dma_addr, MEMTXATTRS_UNSPECIFIED, >> buf, len, is_write); >> +#endif > > Hmm, basically your code splits the transfers so that they don't cross > DMA page boundaries. It seems that your DMA memory region is actually > made of small subregions of size DMA_PAGESIZE aliased to the RAM. Yes, that's the case. I have lots of DMA_PAGESIZE memory region aliases i= n the DMA memory region. > Now looking at the address_space_rw function, it seems it optimizes the > write to RAM case by calling address_space_translate() and then doing a > memcpy() of the whole region. It doesn't work given the memory region i= s > not linear. > > That said address_space_translate is supposed to adjust the length if > needed, but does so only if iommu_ops is defined. Then, the problem lies here. If you can use address_space_rw only on an address range which is linear = in underlying memory region, or if underlying memory region is a iommu, t= hen you have a big problem. As you can't query if=20 that's the case, your only bet is to use address_space_rw with only 1 byt= e quantities... Adding Paolo, as he may have an idea. > I therefore wonder if > you therefore shouldn't model this DMA translation tables by using IOMM= U > ops instead of subregions. > No, in my opinion, that's an implementation detail. Paolo said that it wa= s OK: "Both are okay. The IOMMU makes address space changes faster; your scheme is basically a form of caching, it trades update performance for improved translation performance." http://lists.gnu.org/archive/html/qemu-devel/2015-03/msg05486.html Regards, Herv=E9