Use QEMU_ALIGN_DOWN() macro to reduce code and to make it
more human readable.
Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <b84eb324d2ebdcc6f9c442c97b5b4d01eecb4f43.1632758315.git.qemu_oss@crudebyte.com>
When client sent a 9p Tgetattr request then the wrong I/O block
size value was returned by 9p server; instead of host file
system's I/O block size it should rather return an I/O block
size according to 9p session's 'msize' value, because the value
returned to client should be an "optimum" block size for I/O
(i.e. to maximize performance), it should not reflect the actual
physical block size of the underlying storage media.
The I/O block size of a host filesystem is typically 4k, so the
value returned was far too low for good 9p I/O performance.
This patch adds stat_to_iounit() with a similar approach as the
existing get_iounit() function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1mT2Js-0000DW-OH@lizzy.crudebyte.com>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-4-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-3-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-2-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
- Vector extension bug fixes
- Bit manipulation extension bug fix
- Support vhost-user and numa mem options on all boards
- Rationalise XLEN and operand lengths
- Bump the OpenTitan FPGA support
- Remove the Ibex PLIC
- General code cleanup
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAmFyvkoACgkQIeENKd+X
cFRvOQgAmSgFMu7BbiuLJ7W/0kK/a8vM53+HAMFyFvYiTS7ae2NRmxKyeR/OhFLf
qm36G/SbBhymWAvJysACa7mjvn104WnXkMdhLYGimkne/65IbnQOImzpXk81WP/n
45p/y0DdCs5pP2JNf9aIVxMMzgH2Lo4IgKxLFz+qpnphxtZGjdpocrCz837BOZQH
p61hadfi3rTc06w0Auq8A4Zr+Rp/gpoGzXmB0ujfRGfqi+brg40TV4EAX33e3BJi
249922MbFy2KqqO8H8So9rTZiK4gb/KJ0vGp61nwPcGsf1JPWXpeeb2g6L1syXHW
8J9VezmnIs8bs2SXDvkf0aZpEvDrIA==
=AKR1
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair23/tags/pull-riscv-to-apply-20211022-2' into staging
Fourth RISC-V PR for QEMU 6.2
- Vector extension bug fixes
- Bit manipulation extension bug fix
- Support vhost-user and numa mem options on all boards
- Rationalise XLEN and operand lengths
- Bump the OpenTitan FPGA support
- Remove the Ibex PLIC
- General code cleanup
# gpg: Signature made Fri 22 Oct 2021 06:36:10 AM PDT
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
* remotes/alistair23/tags/pull-riscv-to-apply-20211022-2: (33 commits)
hw/riscv: spike: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: sifive_u: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: sifive_e: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: shakti_c: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: opentitan: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id
hw/intc: sifive_plic: Cleanup the irq_request function
hw/intc: sifive_plic: Cleanup the realize function
hw/intc: sifive_plic: Move the properties
hw/intc: Remove the Ibex PLIC
hw/riscv: opentitan: Update to the latest build
target/riscv: Compute mstatus.sd on demand
target/riscv: Use riscv_csrrw_debug for cpu_dump
target/riscv: Use gen_shift*_per_ol for RVB, RVI
target/riscv: Use gen_unary_per_ol for RVB
target/riscv: Adjust trans_rev8_32 for riscv64
target/riscv: Use gen_arith_per_ol for RVM
target/riscv: Replace DisasContext.w with DisasContext.ol
target/riscv: Replace is_32bit with get_xl/get_xlen
target/riscv: Properly check SEW in amo_op
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* New fp5280g2-bmc board (John)
* Small cleanup in Aspeed SMC model (Cedric)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmFybmYACgkQUaNDx8/7
7KEqzRAAigdJJDS+F7uVYN9srdu8GtbXKRaGYgBcaPIGMzC42Ot9hE46UMUPPbf/
72QXynB09IvtkFgkX7xCaR3Lu1II7Ag+vf/VrjPltX1F05tdj9hTjPflJnPxWbBo
2nTU1vlUPXseaD5HQV/0ygYzqvbqyjCIhjSn0RKoMgKwrimBo52UByemOzh1unbV
nS4eCtQZlUj8ZPiwKViXk1XHscVyQY/7NhTTgdAUzkU74eIlf+op/mMRl3RWMOma
TsarphUoAfzCiYYZwg7IkWZWhTZt/zNR8OslNRfMbRFDfzFicCK3iu9L45jLaUix
W+N8z0xt1QxjWjzAAqHWVaNQion9zZS1Y219pI7rS76FI7m5CNDQ394lD3Pz3fqk
iW1JOtJACL9majRnZ58P7ScdVk68R/2Kt9VVcR93mkL4uAdrdxiWFScMssI1GmwR
CQ6m/Ktupw2YPqx87qNprsjpJriEx7ooU5SGdKpX7eLf2v5pcQRXLArfHOmL6mCe
xK0GGGTyz8E+GqzV8KciZpz9sEz0FoxPyqTjqboArvRPNCGnBvSSBISi24KXPXj3
MnOXiqLQ9BCAQRsSUMvWtof/X6DeAH7eQ8Pfk3+GxmnSsSInT6pOfbDESajMy7SY
ADji7W87JzIPqXO46JCgKU5yXmxaNfUKrJHm5nH0nlmQDUVT21E=
=qbBN
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/clg/tags/pull-aspeed-20211022' into staging
Aspeed patches :
* New fp5280g2-bmc board (John)
* Small cleanup in Aspeed SMC model (Cedric)
# gpg: Signature made Fri 22 Oct 2021 12:55:18 AM PDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/clg/tags/pull-aspeed-20211022:
speed/sdhci: Add trace events
aspeed/smc: Use a container for the flash mmio address space
aspeed: Add support for the fp5280g2-bmc board
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-7-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-6-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
While at it add check for user supplied RAM size and error out if it
mismatches board expected value.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-5-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-4-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
While at it add check for user supplied RAM size and error out if it
mismatches board expected value.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-3-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Message-Id: <20211018132609.160008-6-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Because AddressSpaces must not be sysbus-mapped, commit e9c568dbc2
("hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use
alias") introduced an alias for the flash mmio region.
Using a container is cleaner.
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Message-Id: <20211018132609.160008-5-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The fp5280g2-bmc is supported by OpenBMC, It's
based on the following device tree
https://github.com/openbmc/linux/blob/dev-5.10/arch/arm/boot/dts/aspeed-bmc-inspur-fp5280g2.dts
Signed-off-by: John Wang <wangzhiqiang02@inspur.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211014064548.934799-1-wangzhiqiang02@inspur.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Shortly, the set of supported XL will not be just 32 and 64,
and representing that properly using the enumeration will be
imperative.
Two places, booting and gdb, intentionally use misa_mxl_max
to emphasize the use of the reset value of misa.mxl, and not
the current cpu state.
Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20211020031709.359469-5-richard.henderson@linaro.org
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
If default main_mem is used to be registered as the system memory,
other memory cannot be initialized. Therefore, the system memory
should be initialized to the machine->ram, which consists of the
default main_mem and other possible memory required by applications,
such as shared hugepage memory in DPDK.
Also, the mc->defaul_ram_id should be set to the default main_mem,
such as "riscv_virt_board.ram" for the virt machine.
Signed-off-by: Mingwang Li <limingwang@huawei.com>
Signed-off-by: Yifei Jiang <jiangyifei@huawei.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211016030908.40480-1-limingwang@huawei.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Generate DBG2 table
Switch to ssize_t for elf loader return type
Fixed sbsa cpu type error message typo
Only initialize required submodules for edk2
Dont create device-tree node for empty NUMA node
-----BEGIN PGP SIGNATURE-----
iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmFxhbgdHHJpY2hhcmQu
aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/Z6gf/Wt/iI+cwM8+eNYgV
fFrvkN2YUBS4B7QBVs7axbUmHs+/B8PIyBjo9WLmkMTdgnj13JiXmvE879PZwryr
zlh/2KqKBq+87L5CMOfPXtePizlZI/TuxJL0koIMW/L85ABEYOMyaDp0bDqhJHHb
UNBxvlxHgBmZUpBkmJKWoOKxQ9Jz8M5jpoUjKFCxhMHqbzAQOjS0B0IR6E4n8R4o
pKiWStc2TB7aGtVRY/Jm4EaSy9n3g77K40Yxkn6txN8Eqm/QxCLq9uwEZM2YMR5h
IJUxdUVNT31mCd2EhSAlHqpCrKuFaGCb+t8fQxLkd73AT5Unm5jJl5alfsO8khgV
TgipUA==
=boXv
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/rth/tags/pull-arm-20211021' into staging
Introduce cpu topology support
Generate DBG2 table
Switch to ssize_t for elf loader return type
Fixed sbsa cpu type error message typo
Only initialize required submodules for edk2
Dont create device-tree node for empty NUMA node
# gpg: Signature made Thu 21 Oct 2021 08:22:32 AM PDT
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate]
* remotes/rth/tags/pull-arm-20211021:
tests/data/acpi/virt: Update the empty expected file for PPTT
hw/arm/virt-acpi-build: Generate PPTT table
tests/data/acpi/virt: Add an empty expected file for PPTT
hw/acpi/aml-build: Add PPTT table
hw/acpi/aml-build: Add Processor hierarchy node structure
hw/arm/virt: Add cpu-map to device tree
device_tree: Add qemu_fdt_add_path
hw/arm/virt: Only describe cpu topology since virt-6.2
bios-tables-test: Generate reference table for virt/DBG2
hw/arm/virt_acpi_build: Generate DBG2 table
tests/acpi: Add void table for virt/DBG2 bios-tables-test
hw/elf_ops.h: switch to ssize_t for elf loader return type
hw/arm/sbsa-ref: Fixed cpu type error message typo.
roms/edk2: Only initialize required submodules
roms/edk2: Only init brotli submodule to build BaseTools
hw/arm/virt: Don't create device-tree node for empty NUMA node
tests/acpi: Generate reference blob for IORT rev E.b
hw/arm/virt-acpi-build: IORT upgrade up to revision E.b
tests/acpi: Get prepared for IORT E.b revision upgrade
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Generate the Processor Properties Topology Table (PPTT) for ARM
virt machines supporting it (>= 6.2).
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-Id: <20211020142125.7516-8-wangyanan55@huawei.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add the Processor Properties Topology Table (PPTT) used to
describe CPU topology information to ACPI guests.
Note, a DT-boot Linux guest with a non-flat CPU topology will
see socket and core IDs being sequential integers starting
from zero, which is different from ACPI-boot Linux guest,
e.g. with -smp 4,sockets=2,cores=2,threads=1
a DT boot produces:
cpu: 0 package_id: 0 core_id: 0
cpu: 1 package_id: 0 core_id: 1
cpu: 2 package_id: 1 core_id: 0
cpu: 3 package_id: 1 core_id: 1
an ACPI boot produces:
cpu: 0 package_id: 36 core_id: 0
cpu: 1 package_id: 36 core_id: 1
cpu: 2 package_id: 96 core_id: 2
cpu: 3 package_id: 96 core_id: 3
This is due to several reasons:
1) DT cpu nodes do not have an equivalent field to what the PPTT
ACPI Processor ID must be, i.e. something equal to the MADT CPU
UID or equal to the UID of an ACPI processor container. In both
ACPI cases those are platform dependant IDs assigned by the
vendor.
2) While QEMU is the vendor for a guest, if the topology specifies
SMT (> 1 thread), then, with ACPI, it is impossible to assign a
core-id the same value as a package-id, thus it is not possible
to have package-id=0 and core-id=0. This is because package and
core containers must be in the same ACPI namespace and therefore
must have unique UIDs.
3) ACPI processor containers are not mandatorily required for PPTT
tables to be used and, due to the limitations of which IDs are
selected described above in (2), they are not helpful for QEMU,
so we don't build them with this patch. In the absence of them,
Linux assigns its own unique IDs. The maintainers have chosen not
to use counters from zero, but rather ACPI table offsets, which
explains why the numbers are so much larger than with DT.
4) When there is no SMT (threads=1) the core IDs for ACPI boot guests
match the logical CPU IDs, because these IDs must be equal to the
MADT CPU UID (as no processor containers are present), and QEMU
uses the logical CPU ID for these MADT IDs.
So in summary, with QEMU as the vendor for the guests, we simply
use sequential integers starting from zero for the non-leaf nodes
but with ID-valid flag unset, so that guest will ignore them and
use table offsets as unique container IDs. And we use logical CPU
IDs for the leaf nodes with the ID-valid flag set, which will be
consistent with MADT.
Currently the implementation of PPTT generation complies with ACPI
specification 5.2.29 (Revision 6.3). The 6.3 spec can be found at:
https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Co-developed-by: Yanan Wang <wangyanan55@huawei.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20211020142125.7516-6-wangyanan55@huawei.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add a generic API to build Processor hierarchy node structure (Type 0),
which is strictly consistent with descriptions in ACPI 6.3: 5.2.29.1.
This function will be used to build ACPI PPTT table for cpu topology.
Co-developed-by: Ying Fang <fangying1@huawei.com>
Co-developed-by: Henglong Fan <fanhenglong@huawei.com>
Co-developed-by: Yanan Wang <wangyanan55@huawei.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-Id: <20211020142125.7516-5-wangyanan55@huawei.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Support device tree CPU topology descriptions.
In accordance with the Devicetree Specification, the Linux Doc
"arm/cpus.yaml" requires that cpus and cpu nodes in the DT are
present. And we have already met the requirement by generating
/cpus/cpu@* nodes for members within ms->smp.cpus. Accordingly,
we should also create subnodes in cpu-map for the present cpus,
each of which relates to an unique cpu node.
The Linux Doc "cpu/cpu-topology.txt" states that the hierarchy
of CPUs in a SMP system is defined through four entities and
they are socket/cluster/core/thread. It is also required that
a socket node's child nodes must be one or more cluster nodes.
Given that currently we are only provided with information of
socket/core/thread, we assume there is one cluster child node
in each socket node when creating cpu-map.
Co-developed-by: Yanan Wang <wangyanan55@huawei.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Message-Id: <20211020142125.7516-4-wangyanan55@huawei.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
On existing older machine types, without cpu topology described
in ACPI or DT, the guest will populate one by default. With the
topology described, it will read the information and set up its
topology as instructed, but that may not be the same as what was
getting used by default. It's possible that an user application
has a dependency on the default topology and if the default one
gets changed it will probably behave differently.
Based on above consideration we'd better only describe topology
information to the guest on 6.2 and later machine types.
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20211020142125.7516-2-wangyanan55@huawei.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
ARM SBBR specification mandates DBG2 table (Debug Port Table 2)
since v1.0 (ARM DEN0044F 8.3.1.7 DBG2).
The DBG2 table allows to describe one or more debug ports.
Generate an DBG2 table featuring a single debug port, the PL011.
The DBG2 specification can be found at
"Microsoft Debug Port Table 2 (DBG2)"
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table?redirectedfrom=MSDN
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20211019080037.930641-3-eric.auger@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Recent Linux kernels are accessing the PCI device in slot 0 that
represents the PCI host bridge. This causes ppc4xx_pci_map_irq()
to return -1 which causes an assert() later:
hw/pci/pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
Thus we should allocate an IRQ line for the device in slot 0, too.
To avoid changes to the outside of ppc4xx_pci.c, we map it to
the internal IRQ number 4 which will then happily be ignored since
ppc440_bamboo.c does not wire it up.
With these changes it is now possible again to use recent Linux
kernels for the bamboo board.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211019091817.469003-1-thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This only helps Linux guests as only that seems to use it.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <1c1e030f2bbc86e950b3310fb5922facdc21ef86.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Define a constant for PCI config addresses to make it clearer what
these numbers are.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <9bd8e84d02d91693b71082a1fadeb86e6bce3025.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Instead of relying on the mapped address of the MV64361 registers
access them via their memory region. This is not a problem at reset
time when these registers are mapped at the default address but the
guest could change this later and then the RTAS calls accessing PCI
config registers could fail. None of the guests actually do this so
this only avoids a theoretical problem not seen in practice.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <b6f768023603dc2c4d130720bcecdbea459b7668.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This is needed for Linux to access RTC time.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <6233eb07c680d6c74427e11b9641958f98d53378.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Issue a warning when using VOF (which is the default) but no -kernel
option given to let users know that it will likely fail as the guest
has nothing to run. It is not a hard error because it may still be
useful to start the machine without further options for testing or
inspecting it from monitor without actually booting it.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <a4ec9a900df772b91e9f69ca7a0799d8ae293e5a.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The CHRP spec this board confirms to only allows 2 GiB of system
memory below 4 GiB as the high 2 GiB is allocated to IO and system
resources. To avoid problems with memory overlapping these areas
restrict RAM to 2 GiB similar to mac_newworld.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <54f58229a69c9c1cca21bcecad700b3d7052edd5.1634241019.git.balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When using u-boot as firmware with the taihu board, QEMU aborts with
this assertion:
ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed:
(qemu_mutex_iothread_locked())
Running QEMU with "-d in_asm" shows that the crash happens when writing
to SPR 0x3f2, so we are missing to lock the iothread in the code path
here.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211006071140.565952-1-thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
xive_esb_rw() is the common routine used for memory accesses on ESB
page. Use it for triggers also.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211006210546.641102-1-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 962104f044 ("hw/ppc: moved hcalls that depend on softmmu")
introduced a lot of unnecessary #include directives. Remove them.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211006170801.178023-1-philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 4d9b8ef9b5 ("target/ppc: Fix 64-bit decrementer") introduced
new int64t variables and broke the test triggering the decrementer
exception. Revert partially the change to evaluate both clause of the
if statement.
Reported-by: Coverity CID 1464061
Fixes: 4d9b8ef9b5 ("target/ppc: Fix 64-bit decrementer")
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211005053324.441132-1-clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
and use them to set and test the ASSERTED bit of LSI sources.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211004212141.432954-1-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Until now, int was used as the return type for all the ELF
loader related functions. The returned value is the sum of all loaded
program headers "MemSize" fields.
Because of the overflow check in elf_ops.h, trying to load an ELF bigger
than INT_MAX will fail. Switch to ssize_t to remove this limitation.
Signed-off-by: Luc Michel <lmichel@kalray.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20211014194325.19917-1-lmichel@kalray.eu>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The empty NUMA node, where no memory resides, are allowed. For
example, the following command line specifies two empty NUMA nodes.
With this, QEMU fails to boot because of the conflicting device-tree
node names, as the following error message indicates.
/home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \
-accel kvm -machine virt,gic-version=host \
-cpu host -smp 4,sockets=2,cores=2,threads=1 \
-m 1024M,slots=16,maxmem=64G \
-object memory-backend-ram,id=mem0,size=512M \
-object memory-backend-ram,id=mem1,size=512M \
-numa node,nodeid=0,cpus=0-1,memdev=mem0 \
-numa node,nodeid=1,cpus=2-3,memdev=mem1 \
-numa node,nodeid=2 \
-numa node,nodeid=3
:
qemu-system-aarch64: FDT: Failed to create subnode /memory@80000000: FDT_ERR_EXISTS
As specified by linux device-tree binding document, the device-tree
nodes for these empty NUMA nodes shouldn't be generated. However,
the corresponding NUMA node IDs should be included in the distance
map. The memory hotplug through device-tree on ARM64 isn't existing
so far and it's not necessary to require the user to provide a distance
map. Furthermore, the default distance map Linux generates may even be
sufficient. So this simply skips populating the device-tree nodes for
these empty NUMA nodes to avoid the error, so that QEMU can be started
successfully.
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20211015124246.23073-1-gshan@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
