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 <ard.biesheu...@linaro.org>
> > > > 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 <ard.biesheu...@linaro.org>
> > > > Message-id:
> > > > 1467134090-5099-1-git-send-email-ard.biesheu...@linaro.org
> > > > Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
> > > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> > > >
> > > > > 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 (agraf@achrid) (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
