[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] target-arm: Declare virtio-mmio as dma-coherent

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] target-arm: Declare virtio-mmio as dma-coherent in dt
Date: Thu, 9 Feb 2017 13:43:22 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 09/02/2017 13:30, Ard Biesheuvel wrote:
On 9 February 2017 at 12:24, Alexander Graf <address@hidden> wrote:

On 08/02/2017 17:17, Laszlo Ersek wrote:

On 02/08/17 17:12, Alexander Graf wrote:

On 02/08/2017 04:29 PM, Laszlo Ersek wrote:

CC'ing Ard and Shannon (I recall this property from earlier):

On 02/08/17 14:31, Alexander Graf wrote:

QEMU emulated hardware is always dma coherent with its guest. We do
annotate that correctly on the PCI host controller, but left out

I recommend to reference the following commit here:

commit 5d636e21c44ecf982a22a7bc4ca89186079ac283
Author: Ard Biesheuvel <address@hidden>
Date:   Mon Jul 4 13:06:36 2016 +0100

     hw/arm/virt: mark the PCIe host controller as DMA coherent in the
          Since QEMU performs cacheable accesses to guest memory when
doing DMA
     as part of the implementation of emulated PCI devices, guest
     should use cacheable accesses as well when running under KVM.
Since this
     essentially means that emulated PCI devices are DMA coherent, set
     'dma-coherent' DT property on the PCIe host controller DT node.
          This brings the DT description into line with the ACPI
     which already marks the PCI bridge as cache coherent (see commit
          Signed-off-by: Ard Biesheuvel <address@hidden>
     Reviewed-by: Peter Maydell <address@hidden>
     Signed-off-by: Peter Maydell <address@hidden>

Recent kernels have started to interpret that flag rather than take
dma coherency as granted with virtio-mmio. While that is considered
a kernel bug, as it breaks previously working systems, it showed that
our dt description is incomplete.

This patch adds the respective marker that allows guest OSs to evaluate
that our virtio-mmio devices are indeed cache coherent.

As noted above, commit bc64b96c984a ("hw/arm/virt-acpi-build: _CCA
attribute is compulsory", 2015-11-03) had done the same in the ACPI
description of the PCIe host controller.

Thus, do we need _CCA in the ACPI description of the virtio-mmio
transports, to parallel the DT change? See the LNRO0005 device in

Yes, we should also annotate it correctly in the DSDT. Today it's not a
deal breaker as Linux always assumes virtio-mmio to be dma coherent, but
it would make our platform description more accurate.

If that's the case, then I propose that either the patch please fix
both DT and ACPI, or that at least we file a bug "somewhere", for
adding _CCA in acpi_dsdt_add_virtio().

I agree that it should happen in the same patch (set). While I don't
care a lot about ACPI right now (since dt is preferred on upstream
kernels), I can take a look.

Thank you!

Is ACPI boot supposed to work at all with 4.9?

Yes, but only if you boot via UEFI

I see, thanks. I guess there's no boot protocol to fetch ACPI tables without UEFI.

Interestingly enough, omitting the _CCA property didn't actually make too much of a difference. The guest still seems to boot fine without it, so it seems to treat virtio-mmio as cache coherent. Only if I explicitly set _CCA as 0 it's broken the same as dt.

If that's the case, it's scary if we have different defaults for dt and acpi descriptions, no?

Also, we should probably explicitly warn in the kernel every time we see an ACPI device try to do DMA operations without _CCA set in its descriptor.


reply via email to

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