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

[Andrew Jones]

On Thu, Feb 09, 2017 at 01:24:02PM +0100, Alexander Graf 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 <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.
> > > 
> > > > 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?

It does work. Although you may need to specific console=ttyAMA0.
I think there was/is an issue with getting the default console
out of the SPCR.

> 
> Booting Linux on physical CPU 0x0
> Linux version 4.9.6-00018-g13e39d5 (address@hidden) (gcc version 6.1.1
> 20160711 (Linaro GCC 6.1-2016.08) ) #68 SMP PREEMPT Wed Feb 8 13:25:23 CET
> 2017
> Boot CPU: AArch64 Processor [500f0001]
> efi: Getting EFI parameters from FDT:
> efi: UEFI not found.

Hmm, I'm not sure ACPI boot should work without AAVMF.

Thanks,
drew