lm32/milkymist: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

lm32/lm32_boards: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

x86/pc: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

x86/microvm: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

hppa: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

cris/axis_dev88: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

null-machine: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

s390x/s390-virtio-ccw: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Acked-by: Cornelia Huck <[email protected]>
Tested-by: Halil Pasic <[email protected]>
Acked-by: Halil Pasic <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/xlnx-zcu102: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/xlnx-versal-virt: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/xilinx_zynq: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/xilinx_zynq: drop RAM size fixup

If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.

Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/virt: use memdev for RAM

memory_region_allocate_system_memory() API is going away,
so replace it with memdev allocated MemoryRegion.
The later is initialized by generic code, so board only
needs to opt in to memdev scheme by providing
  MachineClass::default_ram_id
and then map memory region provided by
  MachineState::ram_memdev

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/vexpress: use memdev for RAM

replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/versatilepb: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/sbsa-ref: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/raspi: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
    MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/sabrelite: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 remove no longer needed IMX6Sabrelite

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/palm: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/omap_sx1: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/nseries: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/musicpal: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/mps2: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/mps2-tz: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/mcimx7d-sabre: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 remove no longer needed MCIMX7Sabre

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/mcimx6ul-evk: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
  remove no longer needed MCIMX6ULEVK

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/kzm: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Chubb <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/kzm: drop RAM size fixup

If the user provided too large a RAM size, the code used to
complain and trim it to the max size.  Now that RAM is allocated by
generic code, that's no longer possible, so generate an error and
exit instead.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Chubb <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/integratorcp: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/imx25_pdk: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/imx25_pdk: drop RAM size fixup

If user provided non-sense RAM size, board will complain and
continue running with max RAM size supported.
Also RAM is going to be allocated by generic code, so it won't be
possible for board to fix things up for user.

Make it error message and exit to force user fix CLI,
instead of accepting non-sense CLI values.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/highbank: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/digic_boards: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 remove no longer needed DigicBoardState

PS2:
 while at it add check for user supplied RAM size and error
 out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/cubieboard: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
While at it, get rid of no longer needed CubieBoardState wrapper.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/collie: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

PS:
 - while at it add check for user supplied RAM size and error
   out if it mismatches board expected value.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/aspeed: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Acked-by: Joel Stanley <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

arm/aspeed: actually check RAM size

It's supposed that SOC will check if "-m" provided
RAM size is valid by setting "ram-size" property and
then board would read back valid (possibly corrected
value) to map RAM MemoryReging with valid size.
It isn't doing so, since check is called only
indirectly from
  aspeed_sdmc_reset()->asc->compute_conf()
or much later when guest writes to configuration
register.

So depending on "-m" value QEMU end-ups with a warning
and an invalid MemoryRegion size allocated and mapped.
(examples:
 -M ast2500-evb -m 1M
    0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container
      0000000080000000-00000000800fffff (prio 0, ram): ram
      0000000080100000-00000000bfffffff (prio 0, i/o): max_ram
 -M ast2500-evb -m 3G
    0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container
      0000000080000000-000000013fffffff (prio 0, ram): ram
      [DETECTED OVERFLOW!] 0000000140000000-00000000bfffffff (prio 0, i/o): max_ram
)
On top of that sdmc falls back and reports to guest
"default" size, it thinks machine should have.

This patch makes ram-size check actually work and
changes behavior from a warning later on during
machine reset to error_fatal at the moment SOC.ram-size
is set so user will have to fix RAM size on CLI
to start machine.

It also gets out of the way mutable ram-size logic,
so we could consolidate RAM allocation logic around
pre-allocated hostmem backend (supplied by user or
auto created by generic machine code depending on
supplied -m/mem-path/mem-prealloc options.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

alpha/dp264: use memdev for RAM

memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
  MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

vl.c: ensure that ram_size matches size of machine.memory-backend

Extend set_memory_options() to check that size specified by -m
matches the size of backend pointed by memory-backend.
And in case of -m was omitted adjust ram_size to match that
of explicitly provided backend.

Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <20200219160953[email protected]>

vl.c: move -m parsing after memory backends has been processed

It will be possible for main RAM to come from memory-backend
and we should check that size specified in -m matches the size
of the backend and [MachineState::]ram_size also matches
backend's size.

However -m parsing (set_memory_options()) happens before backends
are intialized (object_create_delayed()) which complicates it.
Consolidate set_memory_options() and assigning parsed results to
current_machine after backends are initialized, so it would be
possible access the initialized backend instance to compare
sizes.

This patch only consolidates scattered places touching ram_size
within vl.c. And follow up patch will integrate backend handling
to set_memory_options().

Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <20200219160953[email protected]>

initialize MachineState::ram in NUMA case

In case of NUMA there are 2 cases to consider:
 1. '-numa node,memdev', the only one that will be available
    for 5.0 and newer machine types.

    In this case reuse current behavior, with only difference
    memdevs are put into MachineState::ram container +
    a temporary glue to keep memory_region_allocate_system_memory()
    working until all boards converted.

 2. fake NUMA ("-numa node mem" and default RAM splitting)
    the later has been deprecated and will be removed but the former
    is going to stay available for compat reasons for 5.0 and
    older machine types

    it takes allocate_system_memory_nonnuma() path, like non-NUMA
    case and falls under conversion to memdev.  So extend non-NUMA
    MachineState::ram initialization introduced in previous patch
    to take care of fake NUMA case.

Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <20200219160953[email protected]>

machine: introduce convenience MachineState::ram

the new field will be used by boards to get access to main
RAM memory region and will help to save boiler plate in
boards which often introduce a field or variable just for
this purpose.

Memory region will be equivalent to what currently used
memory_region_allocate_system_memory() is returning apart
from that it will come from hostmem backend.
Followup patches will incrementally switch boards to using
RAM from MachineState::ram.

Patch takes care of non-NUMA case and follow up patch will
initialize MachineState::ram for NUMA case.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

machine: alias -mem-path and -mem-prealloc into memory-foo backend

Allow machine to opt in for hostmem backend based initial RAM
even if user uses old -mem-path/prealloc options by providing
  MachineClass::default_ram_id
Follow up patches will incrementally convert machines to new API,
by dropping memory_region_allocate_system_memory() and setting
default_ram_id that board used to use before conversion to keep
migration stream the same.

Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <20200219160953[email protected]>

machine: introduce memory-backend property

Property will contain link to memory backend that will be
used for backing initial RAM.
Follow up commit will alias -mem-path and -mem-prealloc
CLI options into memory backend options to make memory
handling consistent (using only hostmem backend family
for guest RAM allocation).

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200219160953[email protected]>

numa: remove deprecated -mem-path fallback to anonymous RAM

it has been deprecated since 4.0 by commit
 cb79224b7 (deprecate -mem-path fallback to anonymous RAM)
Deprecation period ran out and it's time to remove it
so it won't get in a way of switching to using hostmem
backend for RAM.

Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <20200219160953[email protected]>

Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2020-02-15-v2' into staging

Monitor patches for 2020-02-15

# gpg: Signature made Mon 17 Feb 2020 13:26:20 GMT
# gpg:                using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Markus Armbruster <[email protected]>" [full]
# gpg:                 aka "Markus Armbruster <[email protected]>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-monitor-2020-02-15-v2:
  qemu-doc: Clarify extent of build platform support
  monitor: Move qmp_query_qmp_schema to qmp-cmds-control.c
  monitor: Collect "control" command handlers in qmp-cmds.control.c
  qapi: Split control.json off misc.json
  monitor: Move monitor option parsing to monitor/monitor.c

Signed-off-by: Peter Maydell <[email protected]>

qemu-doc: Clarify extent of build platform support

Supporting a build platform beyond its end of life makes no sense.
Spell that out just to be clear.

Signed-off-by: Markus Armbruster <[email protected]>
Message-Id: <20200213084335[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Eduardo Habkost <[email protected]>

monitor: Move qmp_query_qmp_schema to qmp-cmds-control.c

monitor/misc.c contains code that works only in the system emulator, so
it can't be linked to tools like a storage daemon. In order to make
schema introspection available for tools, move the function to
monitor/qmp-cmds-control.c, which can be linked into the storage daemon.

Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200129102239[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

monitor: Collect "control" command handlers in qmp-cmds.control.c

Move all of the QMP commands handlers to implement the 'control' module
(qapi/control.json) that can be shared between the system emulator and
tools such as a storage daemon to a new file monitor/qmp-cmds-control.c.

Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200129102239[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Split control.json off misc.json

misc.json contains definitions that are related to the system emulator,
so it can't be used for other tools like the storage daemon. This patch
moves basic functionality that is shared between all tools (and mostly
related to the monitor itself) into a new control.json, which could be
used in tools as well.

Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200129102239[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

monitor: Move monitor option parsing to monitor/monitor.c

Both the system emulators and tools with QMP support (specifically, the
planned storage daemon) will need to parse monitor options, so move that
code to monitor/monitor.c, which can be linked into binaries that aren't
a system emulator.

Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200129102239[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-5.0-pull-request' into staging

Update syscall numbers to kernel 5.5 level

# gpg: Signature made Mon 17 Feb 2020 09:30:12 GMT
# gpg:                using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Laurent Vivier <[email protected]>" [full]
# gpg:                 aka "Laurent Vivier <[email protected]>" [full]
# gpg:                 aka "Laurent Vivier (Red Hat) <[email protected]>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C

* remotes/vivier2/tags/linux-user-for-5.0-pull-request:
  linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count
  linux-user: xtensa: Update syscall numbers to kernel 5.5 level
  linux-user: x86_64: Update syscall numbers to kernel 5.5 level
  linux-user: sh4: Update syscall numbers to kernel 5.5 level
  linux-user: mips: Update syscall numbers to kernel 5.5 level
  linux-user: microblaze: Update syscall numbers to kernel 5.5 level
  linux-user: m68k: Update syscall numbers to kernel 5.5 level
  linux-user: arm: Update syscall numbers to kernel 5.5 level
  linux-user: alpha: Update syscall numbers to kernel 5.5 level

Signed-off-by: Peter Maydell <[email protected]>

linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count

Currently, there is no usage of TARGET_NR_syscall_count for target
xtensa, and there is no obvious indication if there is some planned
usage in future.

CC: Max Filippov <[email protected]>
Acked-by: Max Filippov <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: xtensa: Update syscall numbers to kernel 5.5 level

Update xtensa syscall numbers based on Linux kernel v5.5.

CC: Max Filippov <[email protected]>
Acked-by: Max Filippov <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: x86_64: Update syscall numbers to kernel 5.5 level

Update x86_64 syscall numbers based on Linux kernel v5.5.

CC: Paolo Bonzini <[email protected]>
CC: Richard Henderson <[email protected]>
CC: Eduardo Habkost <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: sh4: Update syscall numbers to kernel 5.5 level

Update sh4 syscall numbers based on Linux kernel v5.5.

CC: Aurelien Jarno <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: mips: Update syscall numbers to kernel 5.5 level

Update mips syscall numbers based on Linux kernel tag v5.5.

CC: Aurelien Jarno <[email protected]>
CC: Aleksandar Rikalo <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: microblaze: Update syscall numbers to kernel 5.5 level

Update microblaze syscall numbers based on Linux kernel v5.5.

CC: Edgar E. Iglesias <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: m68k: Update syscall numbers to kernel 5.5 level

Update m68k syscall numbers based on Linux kernel v5.5.

CC: Laurent Vivier <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: arm: Update syscall numbers to kernel 5.5 level

Update arm syscall numbers based on Linux kernel v5.5.

CC: Peter Maydell <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

linux-user: alpha: Update syscall numbers to kernel 5.5 level

Update alpha syscall numbers based on Linux kernel v5.5.

CC: Richard Henderson <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Message-Id: <1581596954[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>

Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2020-02-15' into staging

QAPI patches for 2020-02-15

# gpg: Signature made Sat 15 Feb 2020 10:44:28 GMT
# gpg:                using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Markus Armbruster <[email protected]>" [full]
# gpg:                 aka "Markus Armbruster <[email protected]>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-qapi-2020-02-15:
  qapi: Delete all the "foo: dropped in n.n" notes
  qapi/migration.json: Replace _this_ with *this*
  qapi: Add blank lines before bulleted lists
  qapi: Use explicit bulleted lists
  qapi/ui.json: Avoid `...' Texinfo style quoting
  qapi/ui.json: Put input-send-event body text in the right place
  qapi: Remove hardcoded tabs
  qapi: Fix indent level on doc comments in json files
  qapi: Fix incorrect "Not documented" claims in QMP documentation
  qapi/block-core.json: Use literal block for ascii art
  qga/qapi-schema.json: minor format fixups for rST
  qga/qapi-schema.json: Fix indent level on doc comments
  qga/qapi-schema.json: Fix missing '-' in GuestDiskBusType doc comment
  Makefile: Fix typo in dependency list for interop manpages
  configure: Check that sphinx-build is using Python 3
  configure: Pick sphinx-build-3 when available
  configure: Allow user to specify sphinx-build binary
  qapi: Expand documentation for LostTickPolicy

Signed-off-by: Peter Maydell <[email protected]>

qapi: Delete all the "foo: dropped in n.n" notes

A handful of QAPI doc comments include lines like
"ppcemb: dropped in 3.1". The doc comment parser will just
put these into whatever the preceding section was; sometimes
that's "Notes", and sometimes it's some random other section,
as with "NetClientDriver" where the "'dump': dropped in 2.12"
line ends up in the "Since:" section.

This tends to render wrongly, more so in the upcoming rST
generator, but sometimes even in the Texinfo, as in the case
of QKeyCode:
   ac_bookmarks
       since 2.10 altgr, altgr_r: dropped in 2.10

Since commit 3264ffced3 (v4.2.0), we have a better place to tell
users about deprecated and deleted functionality --
qemu-deprecated.texi.  These "dropped in" remarks all predate it, and
other feature drops of that vintage are not documented anywhere, so
moving these to qemu-deprecated.texi makes little sense.  Drop them
instead.

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <20200213175647[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi/migration.json: Replace _this_ with *this*

The MigrationInfo::setup-time documentation is the only place where we
use _this_ inline markup for emphasis, commonly rendered in italics.
We would like to switch the doc comments to rST format, but rST
doesn't recognize that markup and emits literal underscores.

Switch to *this* instead.  Changes markup to strong emphasis with
Texinfo, commonly rendered as bold.  With rST, it will go right back
to emphasis / italics.

rST also uses **this** for strong (commonly rendered bold) where
Texinfo uses *this*. We have one place in the doc comments
which uses strong/bold markup, in qapi/introspect.json:
    Note: the QAPI schema is also used to help define *internal*

When we switch to rST that will be rendered as emphasis / italics.
Markus (who wrote that) thinks that using emphasis / italics
there is an improvement, so we leave that markup alone.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Add blank lines before bulleted lists

We would like to switch the doc comments to rST format. rST
insists on a blank line before and after a bulleted list, but our
Texinfo doc generator did not. Add some extra blank lines in the doc
comments so they're acceptable rST input.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200213175647[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Use explicit bulleted lists

A JSON block comment like this:
     Returns: nothing on success
              If @node is not a valid block device, DeviceNotFound
              If @name is not found, GenericError with an explanation

renders like this:

     Returns: nothing on success If node is not a valid block device,
     DeviceNotFound If name is not found, GenericError with an explanation

because whitespace is not significant.

Use an actual bulleted list, so that the formatting is correct.

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <20200213175647[email protected]>
Message-Id: <20200213175647[email protected]>
Message-Id: <20200213175647[email protected]>
[Three commits squashed into one]
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

qapi/ui.json: Avoid `...' Texinfo style quoting

Avoid Texinfo style quoting with `...', because we would like to
switch the doc comments to rST format, and rST treats it as a syntax
error. Use '...' instead, as we do in other doc comments. This looks
OK in Texinfo, and rST formats it as paired-quotation-marks.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi/ui.json: Put input-send-event body text in the right place

In the doc comment for input-send-event, there is a multi-line
chunk of text ("The @device...take precedence") which is intended
to be the main body text describing the event. However it has
been placed after the arguments and Returns: section, which
means that the parser actually thinks that this text is
part of the "Returns" section text.

Move the body text up to the top so that the parser correctly
classifies it as body.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Remove hardcoded tabs

There are some stray hardcoded tabs in some of our json files;
remove them.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Fix indent level on doc comments in json files

The current doc generation doesn't care much about indentation levels,
but we would like to switch to an rST format, and rST does care about
indentation.

Make the doc comments more strongly consistent about indentation
for multiline constructs like:

@arg: description line 1
      description line 2

Returns: line one
         line 2

so that there is always exactly one space after the colon, and
subsequent lines align with the first.

This commit is a purely whitespace change, and it does not alter the
generated .texi files (because the texi generation code strips away
all the extra whitespace).  This does mean that we end up with some
over-length lines.

Note that when the documentation for an argument fits on a single
line like this:

@arg: one line only

then stray extra spaces after the ':' don't affect the rST output, so
I have not attempted to methodically fix them, though the preference
is a single space here too.

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <20200213175647[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Fix incorrect "Not documented" claims in QMP documentation

Some qapi doc comments have forgotten the ':' after the
@argument, like this:

# @filename         Filename for the new image file
# @size             Size of the virtual disk in bytes

The result is that these are parsed as part of the body
text and appear as a run-on line:
  filename Filename for the new image file size Size of the virtual disk in bytes"
followed by
  filename: string
    Not documented
  size: int
    Not documented

in the 'Members' section.

Correct the formatting.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qapi/block-core.json: Use literal block for ascii art

The ascii-art graph in the BlockLatencyHistogramInfo documentation
doesn't render correctly, because the whitespace is collapsed.

Use the '|' format that emits a literal 'example' block so the graph
is displayed correctly.

Strictly the Texinfo generated is still wrong because each line
goes into its own @example environment, but it renders better
than what we had before.

Fixing this rendering is a necessary prerequisite for the upcoming rST
generator, which otherwise complains about the inconsistent
indentation in the ascii-art graph.

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <20200213175647[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qga/qapi-schema.json: minor format fixups for rST

We would like to switch the doc comments to rST format, and rST
requires a blank line before the start of a bulleted or enumerated
list. Two places in qapi-schema.json were missing this blank line.

Some places were using an indented line as a sort of single-item
bulleted list, which in the Texinfo output comes out all run
onto a single line; use a real bulleted list instead.

Some places unnecessarily indented lists, which confuses rST.

guest-fstrim:minimum's documentation was indented the
right amount to share a line with @minimum, but wasn't
actually doing so.

The indent on the bulleted list in the guest-set-vcpus
Returns section meant rST misindented it.

Changes to the generated Texinfo are very minor (the new
bulleted lists, and a few extra blank lines).

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <20200213175647[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qga/qapi-schema.json: Fix indent level on doc comments

The current doc generation doesn't care much about indentation levels,
but we would like to switch to an rST format, and rST does care about
indentation.

Make the doc comments more strongly consistent about indentation
for multiline constructs like:

@arg: description line 1
      description line 2

Returns: line one
         line 2

so that there is always exactly one space after the colon, and
subsequent lines align with the first.

This commit is a purely whitespace change, and it does not alter the
generated .texi files (because the texi generation code strips away
all the extra whitespace).  This does mean that we end up with some
over-length lines.

Note that when the documentation for an argument fits on a single
line like this:

@arg: one line only

then stray extra spaces after the ':' don't affect the rST output, so
I have not attempted to methodically fix them, though the preference
is a single space here too.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
[Commit message tweaked]
Signed-off-by: Markus Armbruster <[email protected]>

qga/qapi-schema.json: Fix missing '-' in GuestDiskBusType doc comment

The doc comment for GuestDiskBusType doesn't match up with the
enumeration because of a missing hyphen in 'file-backed-virtual'.
This means the docs are rendered wrongly:
       "virtual"
           Win virtual bus type "file-backed" virtual: Win file-backed bus type

       "file-backed-virtual"
           Not documented

Add the missing hyphen.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

Makefile: Fix typo in dependency list for interop manpages

Fix a typo in the dependency list for the manpages built from the
'interop' manual, which meant we were accidentally not including
the .hx file in the dependency list.

Fixes: e13c59fa4414215500e6
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

configure: Check that sphinx-build is using Python 3

Currently configure's has_sphinx_build() check simply runs a dummy
sphinx-build and either passes or fails.  This means that "no
sphinx-build at all" and "sphinx-build exists but is too old" are
both reported the same way.

Further, we want to assume that all the Python we write is running
with at least Python 3.5; configure checks that for our scripts, but
Sphinx extensions run with whatever Python version sphinx-build
itself is using.

Add a check to our conf.py which makes sphinx-build fail if it would
be running our extensions with an old Python, and handle this
in configure so we can report failure helpfully to the user.
This will mean that configure --enable-docs will fail like this
if the sphinx-build provided is not suitable:

Warning: sphinx-build exists but it is either too old or uses too old a Python version

ERROR: User requested feature docs
       configure was not able to find it.
       Install texinfo, Perl/perl-podlators and a Python 3 version of python-sphinx

(As usual, the default is to simply not build the docs, as we would
if sphinx-build wasn't present at all.)

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Wainer dos Santos Moschetta <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

configure: Pick sphinx-build-3 when available

The next commit will require a sphinx-build that uses Python 3.  On
some systems, sphinx-build is fine, on others you need to use
sphinx-build-3.  To keep things working out of the box on both kinds
of systems, try sphinx-build-3, then sphinx-build.

Signed-off-by: Markus Armbruster <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-5.0-sf2' into staging

RISC-V Patches for the 5.0 Soft Freeze, Part 2

This is a fairly light-weight pull request, but I wanted to send it out to
avoid the Goldfish stuff getting buried as the next PR should contain the H
extension implementation.

As far as this PR goes, it contains:

* The addition of syscon device tree nodes for reboot and poweroff, which
  allows Linux to control QEMU without an additional driver.  The existing
  device was already compatible with the syscon interface.
* A fix to our GDB stub to avoid confusing XLEN and FLEN, specifically useful
  for rv32id-based systems.
* A device emulation for the Goldfish RTC device, a simple memory-mapped RTC.
* The addition of the Goldfish RTC device to the RISC-V virt board.

This passes "make check" and boots buildroot for me.

# gpg: Signature made Mon 10 Feb 2020 21:28:04 GMT
# gpg:                using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Palmer Dabbelt <[email protected]>" [unknown]
# gpg:                 aka "Palmer Dabbelt <[email protected]>" [unknown]
# gpg:                 aka "Palmer Dabbelt <[email protected]>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 00CE 76D1 8349 60DF CE88  6DF8 EF4C A150 2CCB AB41
#      Subkey fingerprint: 2B3C 3747 4468 43B2 4A94  3A7A 2E13 19F3 5FBB 1889

* remotes/palmer/tags/riscv-for-master-5.0-sf2:
  MAINTAINERS: Add maintainer entry for Goldfish RTC
  riscv: virt: Use Goldfish RTC device
  hw: rtc: Add Goldfish RTC device
  riscv: Separate FPU register size from core register size in gdbstub [v2]
  riscv/virt: Add syscon reboot and poweroff DT nodes

Signed-off-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/juanquintela/tags/pull-migration-pull-request' into staging

Migration pull request

# gpg: Signature made Thu 13 Feb 2020 13:04:43 GMT
# gpg:                using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <[email protected]>" [full]
# gpg:                 aka "Juan Quintela <[email protected]>" [full]
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03  4B82 F487 EF18 5872 D723

* remotes/juanquintela/tags/pull-migration-pull-request:
  git: Make submodule check only needed modules
  migration-test: fix some memleaks in migration-test
  tests/migration: Add some slack to auto converge
  migration/rdma: rdma_accept_incoming_migration fix error handling
  migration: Optimization about wait-unplug migration state
  migration: Maybe VM is paused when migration is cancelled

Signed-off-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-5.0-pull-request' into staging

Implement TARGET_SO_PEERSEC
Fix rt signals management

# gpg: Signature made Thu 13 Feb 2020 12:20:50 GMT
# gpg:                using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Laurent Vivier <[email protected]>" [full]
# gpg:                 aka "Laurent Vivier <[email protected]>" [full]
# gpg:                 aka "Laurent Vivier (Red Hat) <[email protected]>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C

* remotes/vivier2/tags/linux-user-for-5.0-pull-request:
  linux-user: implement TARGET_SO_PEERSEC
  linux-user: fix use of SIGRTMIN
  linux-user: fix TARGET_NSIG and _NSIG uses
  linux-user: cleanup signal.c
  linux-user: add missing TARGET_SIGRTMIN for hppa

Signed-off-by: Peter Maydell <[email protected]>
# Conflicts:
# linux-user/signal.c

configure: Allow user to specify sphinx-build binary

Currently we insist on using 'sphinx-build' from the $PATH;
allow the user to specify the binary to use. This will be
more useful as we become pickier about the capabilities
we require (eg needing a Python 3 sphinx-build).

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Wainer dos Santos Moschetta <[email protected]>
Message-Id: <20200213175647[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

qapi: Expand documentation for LostTickPolicy

The current documentation is fairly terse and not easy to decode
for someone who's not intimately familiar with the inner workings
of timer devices. Expand on it by providing a somewhat verbose
description of what behavior each policy will result in, as seen
from both the guest OS and host point of view.

Signed-off-by: Andrea Bolognani <[email protected]>
Message-Id: <20200211183744[email protected]>
Reviewed-by: Ján Tomko <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>

Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200213' into staging

target-arm queue:
 * i.MX: Fix inverted sense of register bits in watchdog timer
 * i.MX: Add support for WDT on i.MX6
 * arm/virt: cleanups to ACPI tables
 * Implement ARMv8.1-VMID16 extension
 * Implement ARMv8.1-PAN
 * Implement ARMv8.2-UAO
 * Implement ARMv8.2-ATS1E1
 * ast2400/2500/2600: Wire up EHCI controllers
 * hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
 * hw/arm/raspi: Clean up the board code

# gpg: Signature made Thu 13 Feb 2020 14:40:34 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Peter Maydell <[email protected]>" [ultimate]
# gpg:                 aka "Peter Maydell <[email protected]>" [ultimate]
# gpg:                 aka "Peter Maydell <[email protected]>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20200213: (46 commits)
  target/arm: Implement ARMv8.1-VMID16 extension
  hw/arm/raspi: Extract the cores count from the board revision
  hw/arm/raspi: Use a unique raspi_machine_class_init() method
  hw/arm/raspi: Extract the board model from the board revision
  hw/arm/raspi: Set default RAM size to size encoded in board revision
  hw/arm/raspi: Let class_init() directly call raspi_machine_init()
  hw/arm/raspi: Make board_rev a field of RaspiMachineClass
  hw/arm/raspi: Make machines children of abstract RaspiMachineClass
  hw/arm/raspi: Trivial code movement
  hw/arm/raspi: Extract the processor type from the board revision
  hw/arm/raspi: Extract the RAM size from the board revision
  hw/arm/raspi: Extract the version from the board revision
  hw/arm/raspi: Correct the board descriptions
  hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels
  hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
  hw/arm: ast2600: Wire up EHCI controllers
  hw/arm: ast2400/ast2500: Wire up EHCI controllers
  target/arm: Enable ARMv8.2-UAO in -cpu max
  target/arm: Implement UAO semantics
  target/arm: Update MSR access to UAO
  ...

Signed-off-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/kraxel/tags/vga-20200213-pull-request' into staging

qxl: introduce hardware revision 5

# gpg: Signature made Thu 13 Feb 2020 09:06:14 GMT
# gpg:                using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <[email protected]>" [full]
# gpg:                 aka "Gerd Hoffmann <[email protected]>" [full]
# gpg:                 aka "Gerd Hoffmann (private) <[email protected]>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/vga-20200213-pull-request:
  qxl: introduce hardware revision 5

Signed-off-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200212' into staging

Fix breakpoint invalidation.
Add support for tcg helpers with 7 arguments.
Add support for gvec helpers with 5 arguments.

# gpg: Signature made Thu 13 Feb 2020 00:21:34 GMT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Richard Henderson <[email protected]>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* remotes/rth/tags/pull-tcg-20200212:
  tcg: Add tcg_gen_gvec_5_ptr
  tcg: Add support for a helper with 7 arguments
  exec: flush CPU TB cache in breakpoint_invalidate

Signed-off-by: Peter Maydell <[email protected]>

Merge remote-tracking branch 'remotes/kraxel/tags/usb-20200212-pull-request' into staging

usb: bugfixes

# gpg: Signature made Wed 12 Feb 2020 20:57:44 GMT
# gpg:                using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <[email protected]>" [full]
# gpg:                 aka "Gerd Hoffmann <[email protected]>" [full]
# gpg:                 aka "Gerd Hoffmann (private) <[email protected]>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/usb-20200212-pull-request:
  uas: fix super speed bMaxPacketSize0
  usb-host: wait for cancel complete

Signed-off-by: Peter Maydell <[email protected]>

target/arm: Implement ARMv8.1-VMID16 extension

The ARMv8.1-VMID16 extension extends the VMID from 8 bits to 16 bits:

 * the ID_AA64MMFR1_EL1.VMIDBits field specifies whether the VMID is
   8 or 16 bits
 * the VMID field in VTTBR_EL2 is extended to 16 bits
 * VTCR_EL2.VS lets the guest specify whether to use the full 16 bits,
   or use the backwards-compatible 8 bits

For QEMU implementing this is trivial:
 * we do not track VMIDs in TLB entries, so we never use the VMID field
 * we treat any write to VTTBR_EL2, not just a change to the VMID field
   bits, as a "possible VMID change" that causes us to throw away TLB
   entries, so that code doesn't need changing
 * we allow the guest to read/write the VTCR_EL2.VS bit already

So all that's missing is the ID register part: report that we support
VMID16 in our 'max' CPU.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: 20200210120146[email protected]

hw/arm/raspi: Extract the cores count from the board revision

The count of ARM cores is encoded in the board revision.  Add a
helper to extract the number of cores, and use it.  This will be
helpful when we add the Raspi0/1 that have a single core.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
[PMM: tweaked commit message as suggested by Igor]
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Use a unique raspi_machine_class_init() method

With the exception of the ignore_memory_transaction_failures
flag set for the raspi2, both machine_class_init() methods
are now identical. Merge them to keep a unique method.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Igor Mammedov <[email protected]>
Message-id: 20200208165645[email protected]
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Extract the board model from the board revision

The board revision encode the model type. Add a helper
to extract the model, and use it.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Set default RAM size to size encoded in board revision

We added a helper to extract the RAM size from the board
revision, and made board_rev a field of RaspiMachineClass.
The class_init() can now use the helper to extract from the
board revision the board-specific amount of RAM.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Let class_init() directly call raspi_machine_init()

raspi_machine_init() access to board_rev via RaspiMachineClass.
raspi2_init() and raspi3_init() do nothing. Call raspi_machine_init
directly.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Igor Mammedov <[email protected]>
Message-id: 20200208165645[email protected]
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Make board_rev a field of RaspiMachineClass

We want to have a common class_init(). The only value that
matters (and changes) is the board revision.
Pass the board_rev as class_data to class_init().

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Make machines children of abstract RaspiMachineClass

QOM'ify RaspiMachineState. Now machines inherit of RaspiMachineClass.

Cc: Igor Mammedov <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Igor Mammedov <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Trivial code movement

There is no point in creating the SoC object before allocating the RAM.
Move the call to keep all the SoC-related calls together.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Igor Mammedov <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Extract the processor type from the board revision

The board revision encode the processor type. Add a helper
to extract the type, and use it.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Extract the RAM size from the board revision

The board revision encode the amount of RAM. Add a helper
to extract the RAM size, and use it.
Since the amount of RAM is fixed (it is impossible to physically
modify to have more or less RAM), do not allow sizes different
than the one anounced by the manufacturer.

Acked-by: Igor Mammedov <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Extract the version from the board revision

The board revision encode the board version. Add a helper
to extract the version, and use it.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>

hw/arm/raspi: Correct the board descriptions

We hardcode the board revision as 0xa21041 for the raspi2, and
0xa02082 for the raspi3:

  166 static void raspi_init(MachineState *machine, int version)
  167 {
  ...
  194     int board_rev = version == 3 ? 0xa02082 : 0xa21041;

These revision codes are for the 2B and 3B models, see:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

Correct the board description.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: 20200208165645[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>