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

[Alexander Graf]

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?

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.
cma: Reserved 16 MiB at 0x00000000bf000000
ACPI: Early table checksum verification disabled
fACPI: Failed to init ACPI tables
On node 0 totalpages: 524288
  DMA zone: 8192 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 524288 pages, LIFO batch:31
psci: is not implemented in ACPI.
ACPI: APIC not present
fmissing boot CPU MPIDR, not enabling secondaries
percpu: Embedded 21 pages/cpu @ffff80007efdd000 s47896 r8192 d29928 u86016
pcpu-alloc: s47896 r8192 d29928 u86016 alloc=21*4096
pcpu-alloc: [0] 0
Detected PIPT I-cache on CPU0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 516096
Kernel command line: acpi=force console=ttyAMA0
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2030472K/2097152K available (8380K kernel code, 858K rwdata, 
3632K rodata, 1024K init, 280K bss, 50296K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
    modules : 0xffff000000000000 - 0xffff000008000000   (   128 MB)
    vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000   (129022 GB)
      .text : 0xffff000008080000 - 0xffff0000088b0000   (  8384 KB)
    .rodata : 0xffff0000088b0000 - 0xffff000008c40000   (  3648 KB)
      .init : 0xffff000008c40000 - 0xffff000008d40000   (  1024 KB)
      .data : 0xffff000008d40000 - 0xffff000008e16a00   (   859 KB)
       .bss : 0xffff000008e16a00 - 0xffff000008e5cc3c   (   281 KB)
    fixed   : 0xffff7dfffe7fd000 - 0xffff7dfffec00000   (  4108 KB)
    PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000   (    16 MB)
    vmemmap : 0xffff7e0000000000 - 0xffff800000000000   (  2048 GB maximum)
              0xffff7e0000000000 - 0xffff7e0002000000   (    32 MB actual)
    memory  : 0xffff800000000000 - 0xffff800080000000   (  2048 MB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 64.
        RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
NR_IRQS:64 nr_irqs:64 0
ACPI: APIC not present
ACPI: APIC not present
ACPI: APIC not present
ACPI: APIC not present
ACPI: APIC not present
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.6-00018-g13e39d5 #68
Hardware name: linux,dummy-virt (DT)
Call trace:
[<ffff000008088500>] dump_backtrace+0x0/0x1a0
[<ffff0000080886b4>] show_stack+0x14/0x20
[<ffff000008374e54>] dump_stack+0x94/0xb8
[<ffff0000081658fc>] panic+0x110/0x278
[<ffff000008c424a8>] init_IRQ+0x24/0x2c
[<ffff000008c409f0>] start_kernel+0x230/0x38c
[<ffff000008c401d8>] __primary_switched+0x5c/0x64
---[ end Kernel panic - not syncing: No interrupt controller found.
linux,dummy-virt (DT)


Alex