From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39500)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZHsNp-00048t-Eg
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 07:40:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZHsNm-00046M-8f
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 07:40:21 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54552)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZHsNm-00046H-3K
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 07:40:18 -0400
References: <1437494626-3773-1-git-send-email-markmb@redhat.com>
	<1437494626-3773-3-git-send-email-markmb@redhat.com>
	<55AEA131.3010104@redhat.com> <20150722113015.GA13441@hawk.localdomain>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <55AF811A.5080707@redhat.com>
Date: Wed, 22 Jul 2015 13:40:10 +0200
MIME-Version: 1.0
In-Reply-To: <20150722113015.GA13441@hawk.localdomain>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC 2/7] fw_cfg dma interface
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andrew Jones <drjones@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, 'Kevin O'Connor' <kevin@koconnor.net>, Gerd Hoffmann <kraxel@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?Q?Marc_Mar=c3=ad?= <markmb@redhat.com>

On 07/22/15 13:30, Andrew Jones wrote:
> On Tue, Jul 21, 2015 at 09:44:49PM +0200, Laszlo Ersek wrote:
>> On 07/21/15 18:03, Marc Mar=ED wrote:
>>> +static void fw_cfg_dma_transfer(FWCfgState *s)
>>> +{
>>> +    dma_addr_t len;
>>> +    uint8_t *ptr;
>>> +    uint32_t i;
>>> +
>>> +    if (s->dma_ctl & FW_CFG_DMA_CTL_ERROR) {
>>> +        return;
>>> +    }
>>> +    if (!(s->dma_ctl & FW_CFG_DMA_CTL_READ)) {
>>> +        return;
>>> +    }
>>> +
>>> +    while (s->dma_len > 0) {
>>> +        len =3D s->dma_len;
>>> +        ptr =3D dma_memory_map(s->dma_as, s->dma_addr, &len,
>>> +                             DMA_DIRECTION_FROM_DEVICE);
>>> +        if (!ptr || !len) {
>>> +            s->dma_ctl |=3D FW_CFG_DMA_CTL_ERROR;
>>> +            return;
>>> +        }
>>> +
>>> +        for (i =3D 0; i < len; i++) {
>>> +            ptr[i] =3D fw_cfg_read(s);
>>> +        }
>>> +
>>> +        s->dma_addr +=3D i;
>>> +        s->dma_len  -=3D i;
>>> +        dma_memory_unmap(s->dma_as, ptr, len,
>>> +                         DMA_DIRECTION_FROM_DEVICE, i);
>>> +    }
>>> +    s->dma_ctl =3D 0;
>>> +}
>>
>> On Aarch64 KVM, is this going to show the same cache coherence problem=
s
>> as VGA memory access?
>>
>=20
> Does the guest (AAVMF) need to map all regions it DMAs to/from as
> noncacheable? If so, then yes. If not, then I don't think it should
> map fw-cfg DMA regions that way. fw-cfg is a paravirt device, so I
> don't think we should have to treat it like a real one.

I'd just point the address registers (or the address fields in the
descriptor structure) to a block of normal guest RAM, before flipping
the appropriate bit in the MMIO register that actually fires off the
transfer.

... Seems like that should work, then. Thanks!

Laszlo