spapr_pci: don't create 64-bit MMIO window if we don't need to
commit96dbc9af35eb6672a3b531da8bba521ce46c26dc
authorGreg Kurz <groug@kaod.org>
Mon, 11 Sep 2017 10:14:19 +0000 (11 12:14 +0200)
committerDavid Gibson <david@gibson.dropbear.id.au>
Fri, 15 Sep 2017 00:29:48 +0000 (15 10:29 +1000)
treed680fa10bd24a7d809650f2f2a4a568a68677b02
parent1d36da769a4e390a63db1d44114741bb924acdd6
spapr_pci: don't create 64-bit MMIO window if we don't need to

When running a pseries-2.2 or older machine type, we get the following
lines in info mtree:

address-space: memory
...
ffffffffffffffff-ffffffffffffffff (prio 0, i/o): alias
 pci@800000020000000.mmio64-alias @pci@800000020000000.mmio
  ffffffffffffffff-ffffffffffffffff

address-space: cpu-memory
...
ffffffffffffffff-ffffffffffffffff (prio 0, i/o): alias
 pci@800000020000000.mmio64-alias @pci@800000020000000.mmio
  ffffffffffffffff-ffffffffffffffff

The same thing occurs when running a pseries-2.7 with

    -global spapr-pci-host-bridge.mem_win_size=2147483648

This happens because we always create a 64-bit MMIO window, even if
we didn't explicitely requested it (ie, mem64_win_size == 0) and the
32-bit window is below 2GiB. It doesn't seem to have an impact on the
guest though because spapr_populate_pci_dt() doesn't advertise the
bogus windows when mem64_win_size == 0.

Since these memory regions don't induce any state, we can safely
choose to not create them when their address is equal to -1,
without breaking migration from existing setups.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
hw/ppc/spapr_pci.c