On 9 February 2017 at 12:29, Alexander Graf <[email protected]> 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 >>>>> virtio-mmio. >>>> >>>> I recommend to reference the following commit here: >>>> >>>> commit 5d636e21c44ecf982a22a7bc4ca89186079ac283 >>>> Author: Ard Biesheuvel <[email protected]> >>>> 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 <[email protected]> >>>> Message-id: >>>> [email protected] >>>> Reviewed-by: Peter Maydell <[email protected]> >>>> Signed-off-by: Peter Maydell <[email protected]> >>>> >>>>> 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. >>> >>>> 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! > > > In fact, don't some other devices also suffer from this? Fw-cfg is now DMA > capable IIUC, so that should also get a _CCA attribute for example. >
Correct. Any described DMA capable device should have a _CCA attribute
