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

[Ard Biesheuvel]

> On 8 Feb 2017, at 16:17, Laszlo Ersek <address@hidden> 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
>>>> virtio-mmio.
>>> 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 DT
>>>          Since QEMU performs cacheable accesses to guest memory when
>>> doing DMA
>>>     as part of the implementation of emulated PCI devices, guest drivers
>>>     should use cacheable accesses as well when running under KVM.
>>> Since this
>>>     essentially means that emulated PCI devices are DMA coherent, set
>>> the
>>>     'dma-coherent' DT property on the PCIe host controller DT node.
>>>          This brings the DT description into line with the ACPI
>>> description,
>>>     which already marks the PCI bridge as cache coherent (see commit
>>>     bc64b96c984abf).
>>>          Signed-off-by: Ard Biesheuvel <address@hidden>
>>>     Message-id:
>>> 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
>>> acpi_dsdt_add_virtio().
>> 
>> 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.
>> 

The _CCA property is mandatory on arm64, and there is no default. So this is a 
bug nonetheless, even if the de facto default matches the platform. So yes, 
let's get this fixed please.


>>> 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!
> Laszlo
>