aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-09tracing: remove the trace-tcg includes from the buildAlex Bennée4-9/+0
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-20-alex.bennee@linaro.org>
2022-02-09tracing: remove TCG memory access tracingAlex Bennée6-67/+0
If you really want to trace all memory operations TCG plugins gives you a more flexible interface for doing so. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-19-alex.bennee@linaro.org>
2022-02-09docs: remove references to TCG tracingAlex Bennée2-85/+13
Users wanting this sort of functionality should turn to TCG plugins instead. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-18-alex.bennee@linaro.org>
2022-02-09tests/tcg/sh4: disable another unreliable testAlex Bennée1-0/+4
Given the other failures it looks like general thread handling on sh4 is sketchy. It fails more often on CI than on my developer machine though. See https://gitlab.com/qemu-project/qemu/-/issues/856 for more details. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Laurent Vivier <laurent@vivier.eu> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-17-alex.bennee@linaro.org>
2022-02-09tests: Update CentOS 8 container to CentOS Stream 8Thomas Huth2-3/+3
Support for CentOS 8 has stopped at the end of 2021, so let's switch to the Stream variant instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220201101911.97900-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-16-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Allow lcitool-refresh in out-of-tree builds, tooThomas Huth1-1/+1
When running "make lcitool-refresh" in an out-of-tree build, it currently fails with an error message from git like this: fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Fix it by changing to the source directory first before updating the submodule. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220201085554.85733-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-15-alex.bennee@linaro.org>
2022-02-09gitlab: fall back to commit hash in qemu-setup filenameStefan Hajnoczi1-1/+1
Personal repos may not have release tags (v6.0.0, v6.1.0, etc) and this causes cross_system_build_job to fail when pretty-printing a unique qemu-setup-*.exe name: version="$(git describe --match v[0-9]*)"; ^^^^^^^^^^ fails ^^^^^^^^^^^ mv -v qemu-setup*.exe qemu-setup-${version}.exe; Fall back to the short commit hash if necessary. This fixes CI failures that Greg Kurz and I experienced in our personal repos. Cc: Greg Kurz <groug@kaod.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220125173454.10381-1-stefanha@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-14-alex.bennee@linaro.org>
2022-02-09docs/devel: mention our .editorconfigAlex Bennée1-0/+4
Ideally we should keep all our automatic formatting gubins in here. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-13-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Install libibumad to cover RDMA on Debian based distrosPhilippe Mathieu-Daudé3-0/+3
On Debian we also need libibumad to enable RDMA: $ ../configure --enable-rdma ERROR: OpenFabrics librdmacm/libibverbs/libibumad not present. Your options: (1) Fast: Install infiniband packages (devel) from your distro. (2) Cleanest: Install libraries from www.openfabrics.org (3) Also: Install softiwarp if you don't have RDMA hardware Add the dependency to lcitool's qemu.yml (where librdmacm and libibverbs are already listed) and refresh the generated files by running: $ make lcitool-refresh Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-8-f4bug@amsat.org> Message-Id: <20220204204335.1689602-12-alex.bennee@linaro.org>
2022-02-09tests: Manually remove libxml2 on MSYS2 runnersPhilippe Mathieu-Daudé2-3/+0
lcitool doesn't support MSYS2 targets, so manually remove this now unnecessary library. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-7-f4bug@amsat.org> Message-Id: <20220204204335.1689602-11-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Refresh submodule and remove libxml2Philippe Mathieu-Daudé11-18/+10
The previous commit removed all uses of libxml2. Refresh lcitool submodule, update qemu.yml and refresh the generated files by running: $ make lcitool-refresh Note: This refreshment also removes libudev dependency on Fedora and CentOS due to libvirt-ci commit 18bfaee ("mappings: Improve mapping for libudev"), since "The udev project has been absorbed by the systemd project", and lttng-ust on FreeBSD runners due to libvirt-ci commit 6dd9b6f ("guests: drop lttng-ust from FreeBSD platform"). Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-6-f4bug@amsat.org> Message-Id: <20220204204335.1689602-10-alex.bennee@linaro.org>
2022-02-09drop libxml2 checks since libxml is not actually used (for parallels)Michael Tokarev8-17/+2
For a long time, we assumed that libxml2 is necessary for parallels block format support (block/parallels*). However, this format actually does not use libxml [*]. Since this is the only user of libxml2 in whole QEMU tree, we can drop all libxml2 checks and dependencies too. It is even more: --enable-parallels configure option was the only option which was silently ignored when it's (fake) dependency (libxml2) isn't installed. Drop all mentions of libxml2. [*] Actually the basis for libxml use were introduced in commit ed279a06c53 ("configure: add dependency") but the implementation was never merged: https://lore.kernel.org/qemu-devel/70227bbd-a517-70e9-714f-e6e0ec431be9@openvz.org/ Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220119090423.149315-1-mjt@msgid.tls.msk.ru> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMD: Updated description and adapted to use lcitool] Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-5-f4bug@amsat.org> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20220204204335.1689602-9-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Include local qemu.yml when refreshing cirrus-ci filesPhilippe Mathieu-Daudé1-1/+1
The script only include the local qemu.yml for Dockerfiles. Since we want to keep the Cirrus-CI generated files in sync, also use the --data-dir option in generate_cirrus(). Fixes: c45a540f4bd (".gitlab-ci.d/cirrus: auto-generate variables with lcitool") Reported-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-4-f4bug@amsat.org> Message-Id: <20220204204335.1689602-8-alex.bennee@linaro.org>
2022-02-09gitmodules: Correct libvirt-ci submodule URLPhilippe Mathieu-Daudé1-1/+1
Correct the libvirt-ci repository URL to avoid this warning when cloning / refreshing the submodule: warning: redirecting to https://gitlab.com/libvirt/libvirt-ci.git/ Fixes: 4ebb040f1fd ("tests: integrate lcitool for generating build env manifests") Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-3-f4bug@amsat.org> Message-Id: <20220204204335.1689602-7-alex.bennee@linaro.org>
2022-02-09MAINTAINERS: Cover lcitool submodule with build test / automationPhilippe Mathieu-Daudé1-0/+1
lcitool is used by build test / automation, we want maintainers to get notified if the submodule is updated. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-2-f4bug@amsat.org> Message-Id: <20220204204335.1689602-6-alex.bennee@linaro.org>
2022-02-09.gitignore: add .gcov patternAlex Bennée1-0/+1
The gcovr tool is very messy and can leave a lot of crap in the source tree even when using build directories. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220204204335.1689602-5-alex.bennee@linaro.org>
2022-02-09Makefile: also remove .gcno files when cleaningAlex Bennée1-1/+2
Left over .gcno files from old builds can really confuse gcov and the user expects a clean slate after "make clean". Make clean mean clean. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-4-alex.bennee@linaro.org>
2022-02-09tests/qtest: enable more vhost-user tests by defaultAlex Bennée1-12/+9
If this starts causing failures again we should probably fix that. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Message-Id: <20220204204335.1689602-3-alex.bennee@linaro.org>
2022-02-09tests/Makefile.include: clean-up old codeAlex Bennée1-4/+0
This is no longer needed since a2ce7dbd91 ("meson: convert tests/qtest to meson", 2020-08-21) Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-2-alex.bennee@linaro.org>
2022-02-08Merge remote-tracking branch ↵Peter Maydell42-614/+1302
'remotes/pmaydell/tags/pull-target-arm-20220208' into staging target-arm queue: * Fix handling of SVE ZCR_LEN when using VHE * xlnx-zynqmp: 'Or' the QSPI / QSPI DMA IRQs * Don't ever enable PSCI when booting guest in EL3 * Adhere to SMCCC 1.3 section 5.2 * highbank: Fix issues with booting SMP * midway: Fix issues booting at all * boot: Drop existing dtb /psci node rather than retaining it * versal-virt: Always call arm_load_kernel() * force flag recalculation when messing with DAIF * hw/timer/armv7m_systick: Update clock source before enabling timer * hw/arm/smmuv3: Fix device reset * hw/intc/arm_gicv3_its: refactorings and minor bug fixes * hw/sensor: Add lsm303dlhc magnetometer device # gpg: Signature made Tue 08 Feb 2022 11:39:15 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20220208: (39 commits) hw/sensor: Add lsm303dlhc magnetometer device hw/intc/arm_gicv3_its: Split error checks hw/intc/arm_gicv3_its: Don't allow intid 1023 in MAPI/MAPTI hw/intc/arm_gicv3_its: In MAPC with V=0, don't check rdbase field hw/intc/arm_gicv3_its: Drop TableDesc and CmdQDesc valid fields hw/intc/arm_gicv3_its: Make update_ite() use ITEntry hw/intc/arm_gicv3_its: Pass ITE values back from get_ite() via a struct hw/intc/arm_gicv3_its: Avoid nested ifs in get_ite() hw/intc/arm_gicv3_its: Fix address calculation in get_ite() and update_ite() hw/intc/arm_gicv3_its: Pass CTEntry to update_cte() hw/intc/arm_gicv3_its: Keep CTEs as a struct, not a raw uint64_t hw/intc/arm_gicv3_its: Pass DTEntry to update_dte() hw/intc/arm_gicv3_its: Keep DTEs as a struct, not a raw uint64_t hw/intc/arm_gicv3_its: Use address_space_map() to access command queue packets hw/arm/smmuv3: Fix device reset hw/timer/armv7m_systick: Update clock source before enabling timer arm: force flag recalculation when messing with DAIF hw/arm: versal-virt: Always call arm_load_kernel() hw/arm/boot: Drop existing dtb /psci node rather than retaining it hw/arm/boot: Drop nb_cpus field from arm_boot_info ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/sensor: Add lsm303dlhc magnetometer deviceKevin Townsend5-0/+710
This commit adds emulation of the magnetometer on the LSM303DLHC. It allows the magnetometer's X, Y and Z outputs to be set via the mag-x, mag-y and mag-z properties, as well as the 12-bit temperature output via the temperature property. Sensor can be enabled with 'CONFIG_LSM303DLHC_MAG=y'. Signed-off-by: Kevin Townsend <kevin.townsend@linaro.org> Message-id: 20220130095032.35392-1-kevin.townsend@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/intc/arm_gicv3_its: Split error checksPeter Maydell1-21/+31
In most of the ITS command processing, we check different error possibilities one at a time and log them appropriately. In process_mapti() and process_mapd() we have code which checks multiple error cases at once, which means the logging is less specific than it could be. Split those cases up. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-14-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Don't allow intid 1023 in MAPI/MAPTIPeter Maydell1-2/+1
When handling MAPI/MAPTI, we allow the supplied interrupt ID to be either 1023 or something in the valid LPI range. This is a mistake: only a real valid LPI is allowed. (The general behaviour of the ITS is that most interrupt ID fields require a value in the LPI range; the exception is that fields specifying a doorbell value, which are all in GICv4 commands, allow also 1023 to mean "no doorbell".) Remove the condition that incorrectly allows 1023 here. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-13-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: In MAPC with V=0, don't check rdbase fieldPeter Maydell1-12/+12
In the MAPC command, if V=0 this is a request to delete a collection table entry and the rdbase field of the command packet will not be used. In particular, the specification says that the "UNPREDICTABLE if rdbase is not valid" only applies for V=1. We were doing a check-and-log-guest-error on rdbase regardless of whether the V bit was set, and also (harmlessly but confusingly) storing the contents of the rdbase field into the updated collection table entry. Update the code so that if V=0 we don't check or use the rdbase field value. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-12-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Drop TableDesc and CmdQDesc valid fieldsPeter Maydell2-19/+14
Currently we track in the TableDesc and CmdQDesc structs the state of the GITS_BASER<n> and GITS_CBASER Valid bits. However we aren't very consistent abut checking the valid field: we test it in update_cte() and update_dte(), but not anywhere else we look things up in tables. The GIC specification says that it is UNPREDICTABLE if a guest fails to set any of these Valid bits before enabling the ITS via GITS_CTLR.Enabled. So we can choose to handle Valid == 0 as equivalent to a zero-length table. This is in fact how we're already catching this case in most of the table-access paths: when Valid is 0 we leave the num_entries fields in TableDesc or CmdQDesc set to zero, and then the out-of-bounds check "index >= num_entries" that we have to do anyway before doing any of these table lookups will always be true, catching the no-valid-table case without any extra code. So we can remove the checks on the valid field from update_cte() and update_dte(): since these happen after the bounds check there was never any case when the test could fail. That means the valid fields would be entirely unused, so just remove them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-11-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Make update_ite() use ITEntryPeter Maydell1-30/+32
Make the update_ite() struct use the new ITEntry struct, so that callers don't need to assemble the in-memory ITE data themselves, and only get_ite() and update_ite() need to care about that in-memory layout. We can then drop the no-longer-used IteEntry struct definition. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-10-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Pass ITE values back from get_ite() via a structPeter Maydell1-47/+55
In get_ite() we currently return the caller some of the fields of an Interrupt Table Entry via a set of pointer arguments, and validate some of them internally (interrupt type and valid bit) to return a simple true/false 'valid' indication. Define a new ITEntry struct which has all the fields that the in-memory ITE has, and bring the get_ite() function in to line with get_dte() and get_cte(). This paves the way for handling virtual interrupts, which will want a different subset of the fields in the ITE. Handling them under the old "lots of pointer arguments" scheme would have meant a confusingly large set of arguments for this function. The new struct ITEntry is obviously confusably similar to the existing IteEntry struct, whose fields are the raw 12 bytes of the in-memory ITE. In the next commit we will make update_ite() use ITEntry instead of IteEntry, which will allow us to delete the IteEntry struct and remove the confusion. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-9-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Avoid nested ifs in get_ite()Peter Maydell1-13/+15
The get_ite() code has some awkward nested if statements; clean them up by returning early if the memory accesses fail. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-8-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Fix address calculation in get_ite() and update_ite()Peter Maydell2-26/+21
In get_ite() and update_ite() we work with a 12-byte in-guest-memory table entry, which we intend to handle as an 8-byte value followed by a 4-byte value. Unfortunately the calculation of the address of the 4-byte value is wrong, because we write it as: table_base_address + (index * entrysize) + 4 (obfuscated by the way the expression has been written) when it should be + 8. This bug meant that we overwrote the top bytes of the 8-byte value with the 4-byte value. There are no guest-visible effects because the top half of the 8-byte value contains only the doorbell interrupt field, which is used only in GICv4, and the two bugs in the "write ITE" and "read ITE" codepaths cancel each other out. We can't simply change the calculation, because this would break migration of a (TCG) guest from the old version of QEMU which had in-guest-memory interrupt tables written using the buggy version of update_ite(). We must also at the same time change the layout of the fields within the ITE_L and ITE_H values so that the in-memory locations of the fields we care about (VALID, INTTYPE, INTID and ICID) stay the same. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-7-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Pass CTEntry to update_cte()Peter Maydell1-15/+17
Make update_cte() take a CTEntry struct rather than all the fields of the new CTE as separate arguments. This brings it into line with the update_dte() API. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-6-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Keep CTEs as a struct, not a raw uint64_tPeter Maydell1-44/+52
In the ITS, a CTE is an entry in the collection table, which contains multiple fields. Currently the function get_cte() which reads one entry from the device table returns a success/failure boolean and passes back the raw 64-bit integer CTE value via a pointer argument. We then extract fields from the CTE as we need them. Create a real C struct with the same fields as the CTE, and populate it in get_cte(), so that that function and update_cte() are the only ones which need to care about the in-guest-memory format of the CTE. This brings get_cte()'s API into line with get_dte(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-5-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Pass DTEntry to update_dte()Peter Maydell1-17/+18
Make update_dte() take a DTEntry struct rather than all the fields of the new DTE as separate arguments. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-4-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Keep DTEs as a struct, not a raw uint64_tPeter Maydell1-55/+56
In the ITS, a DTE is an entry in the device table, which contains multiple fields. Currently the function get_dte() which reads one entry from the device table returns it as a raw 64-bit integer, which we then pass around in that form, only extracting fields from it as we need them. Create a real C struct with the same fields as the DTE, and populate it in get_dte(), so that that function and update_dte() are the only ones that need to care about the in-guest-memory format of the DTE. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-3-peter.maydell@linaro.org
2022-02-08hw/intc/arm_gicv3_its: Use address_space_map() to access command queue packetsPeter Maydell2-149/+61
Currently the ITS accesses each 8-byte doubleword in a 4-doubleword command packet with a separate address_space_ldq_le() call. This is awkward because the individual command processing functions have ended up with code to handle "load more doublewords out of the packet", which is both unwieldy and also a potential source of bugs because it's not obvious when looking at a line that pulls a field out of the 'value' variable which of the 4 doublewords that variable currently holds. Switch to using address_space_map() to map the whole command packet at once and fish the four doublewords out of it. Then each process_* function can start with a few lines of code that extract the fields it cares about. This requires us to split out the guts of process_its_cmd() into a new do_process_its_cmd(), because we were previously overloading the value and offset arguments as a backdoor way to directly pass the devid and eventid from a write to GITS_TRANSLATER. The new do_process_its_cmd() takes those arguments directly, and process_its_cmd() is just a wrapper that does the "read fields from command packet" part. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220201193207.2771604-2-peter.maydell@linaro.org
2022-02-08hw/arm/smmuv3: Fix device resetEric Auger1-0/+6
We currently miss a bunch of register resets in the device reset function. This sometimes prevents the guest from rebooting after a system_reset (with virtio-blk-pci). For instance, we may get the following errors: invalid STE smmuv3-iommu-memory-region-0-0 translation failed for iova=0x13a9d2000(SMMU_EVT_C_BAD_STE) Invalid read at addr 0x13A9D2000, size 2, region '(null)', reason: rejected invalid STE smmuv3-iommu-memory-region-0-0 translation failed for iova=0x13a9d2000(SMMU_EVT_C_BAD_STE) Invalid write at addr 0x13A9D2000, size 2, region '(null)', reason: rejected invalid STE Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-id: 20220202111602.627429-1-eric.auger@redhat.com Fixes: 10a83cb988 ("hw/arm/smmuv3: Skeleton") Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/timer/armv7m_systick: Update clock source before enabling timerRichard Petri1-4/+4
Starting the SysTick timer and changing the clock source a the same time will result in an error, if the previous clock period was zero. For exmaple, on the mps2-tz platforms, no refclk is present. Right after reset, the configured ptimer period is zero, and trying to enabling it will turn it off right away. E.g., code running on the platform setting SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk; should change the clock source and enable the timer on real hardware, but resulted in an error in qemu. Signed-off-by: Richard Petri <git@rpls.de> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20220201192650.289584-1-git@rpls.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08arm: force flag recalculation when messing with DAIFAlex Bennée1-0/+2
The recently introduced debug tests in kvm-unit-tests exposed an error in our handling of singlestep cause by stale hflags. This is caught by --enable-debug-tcg when running the tests. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reported-by: Andrew Jones <drjones@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220202122353.457084-1-alex.bennee@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm: versal-virt: Always call arm_load_kernel()Edgar E. Iglesias1-9/+2
Always call arm_load_kernel() regardless of kernel_filename being set. This is needed because arm_load_kernel() sets up reset for the CPUs. Fixes: 6f16da53ff (hw/arm: versal: Add a virtual Xilinx Versal board) Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 20220130110313.4045351-2-edgar.iglesias@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm/boot: Drop existing dtb /psci node rather than retaining itPeter Maydell1-3/+4
If we're using PSCI emulation, we add a /psci node to the device tree we pass to the guest. At the moment, if the dtb already has a /psci node in it, we retain it, rather than replacing it. (This behaviour was added in commit c39770cd637765 in 2018.) This is a problem if the existing node doesn't match our PSCI emulation. In particular, it might specify the wrong method (HVC vs SMC), or wrong function IDs for cpu_suspend/cpu_off/etc, in which case the guest will not get the behaviour it wants when it makes PSCI calls. An example of this is trying to boot the highbank or midway board models using the device tree supplied in the kernel sources: this device tree includes a /psci node that specifies function IDs that don't match the (PSCI 0.2 compliant) IDs that QEMU uses. The dtb cpu_suspend function ID happens to match the PSCI 0.2 cpu_off ID, so the guest hangs after booting when the kernel tries to idle the CPU and instead it gets turned off. Instead of retaining an existing /psci node, delete it entirely and replace it with a node whose properties match QEMU's PSCI emulation behaviour. This matches the way we handle /memory nodes, where we also delete any existing nodes and write in ones that match the way QEMU is going to behave. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-17-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Drop nb_cpus field from arm_boot_infoPeter Maydell18-26/+5
We use the arm_boot_info::nb_cpus field in only one place, and that place can easily get the number of CPUs locally rather than relying on the board code to have set the field correctly. (At least one board, xlnx-versal-virt, does not set the field despite having more than one CPU.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-16-peter.maydell@linaro.org
2022-02-08hw/arm/highbank: Drop unused secondary boot stub codePeter Maydell1-56/+0
The highbank and midway board code includes boot-stub code for handling secondary CPU boot which keeps the secondaries in a pen until the primary writes to a known location with the address they should jump to. This code is never used, because the boards enable QEMU's PSCI emulation, so secondary CPUs are kept powered off until the PSCI call which turns them on, and then start execution from the address given by the guest in that PSCI call. Delete the unreachable code. (The code was wrong for midway in any case -- on the Cortex-A15 the GIC CPU interface registers are at a different offset from PERIPHBASE compared to the Cortex-A9, and the code baked-in the offsets for highbank's A9.) Note that this commit implicitly depends on the preceding "Don't write secondary boot stub if using PSCI" commit -- the default secondary-boot stub code overlaps with one of the highbank-specific bootcode rom blobs, so we must suppress the secondary-boot stub code entirely, not merely replace the highbank-specific version with the default. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-15-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Don't write secondary boot stub if using PSCIPeter Maydell2-11/+27
If we're using PSCI emulation to start secondary CPUs, there is no point in writing the "secondary boot" stub code, because it will never be used -- secondary CPUs start powered-off, and when powered on are set to begin execution at the address specified by the guest's power-on PSCI call, not at the stub. Move the call to the hook that writes the secondary boot stub code so that we can do it only if we're starting a Linux kernel and not using PSCI. (None of the users of the hook care about the ordering of its call relative to anything else: they only use it to write a rom blob to guest memory.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-14-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Prevent setting both psci_conduit and secure_board_setupPeter Maydell1-0/+10
Now that we have dealt with the one special case (highbank) that needed to set both psci_conduit and secure_board_setup, we don't need to allow that combination any more. It doesn't make sense in general, so use an assertion to ensure we don't add new boards that do it by accident without thinking through the consequences. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-13-peter.maydell@linaro.org
2022-02-08hw/arm/highbank: Drop use of secure_board_setupPeter Maydell1-8/+0
Guest code on highbank may make non-PSCI SMC calls in order to enable/disable the L2x0 cache controller (see the Linux kernel's arch/arm/mach-highbank/highbank.c highbank_l2c310_write_sec() function). The ABI for this is documented in kernel commit 8e56130dcb as being borrowed from the OMAP44xx ROM. The OMAP44xx TRM documents this function ID as having no return value and potentially trashing all guest registers except SP and PC. For QEMU's purposes (where our L2x0 model is a stub and enabling or disabling it doesn't affect the guest behaviour) a simple "do nothing" SMC is fine. We currently implement this NOP behaviour using a little bit of Secure code we run before jumping to the guest kernel, which is written by arm_write_secure_board_setup_dummy_smc(). The code sets up a set of Secure vectors where the SMC entry point returns without doing anything. Now that the PSCI SMC emulation handles all SMC calls (setting r0 to an error code if the input r0 function identifier is not recognized), we can use that default behaviour as sufficient for the highbank cache controller call. (Because the guest code assumes r0 has no interesting value on exit it doesn't matter that we set it to the error code). We can therefore delete the highbank board code that sets secure_board_setup to true and writes the secure-code bootstub. (Note that because the OMAP44xx ABI puts function-identifiers in r12 and PSCI uses r0, we only avoid a clash because Linux's code happens to put the function-identifier in both registers. But this is true also when the kernel is running on real firmware that implements both ABIs as far as I can see.) This change fixes in passing booting on the 'midway' board model, which has been completely broken since we added support for Hyp mode to the Cortex-A15 CPU. When we did that boot.c was made to start running the guest code in Hyp mode; this includes the board_setup hook, which instantly UNDEFs because the NSACR is not accessible from Hyp. (Put another way, we never made the secure_board_setup hook support cope with Hyp mode.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-12-peter.maydell@linaro.org
2022-02-08arm: tcg: Adhere to SMCCC 1.3 section 5.2Peter Maydell1-29/+6
The SMCCC 1.3 spec section 5.2 says The Unknown SMC Function Identifier is a sign-extended value of (-1) that is returned in the R0, W0 or X0 registers. An implementation must return this error code when it receives: * An SMC or HVC call with an unknown Function Identifier * An SMC or HVC call for a removed Function Identifier * An SMC64/HVC64 call from AArch32 state To comply with these statements, let's always return -1 when we encounter an unknown HVC or SMC call. [PMM: This is a reinstatement of commit 9fcd15b9193e819b, previously reverted in commit 4825eaae4fdd56fba0f; we can do this now that we have arranged for all the affected board models to not enable the PSCI emulation if they are running guest code at EL3. This avoids the regressions that caused us to revert the change for 7.0.] Signed-off-by: Alexander Graf <agraf@csgraf.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-08hw/arm: highbank: For EL3 guests, don't enable PSCI, start all coresPeter Maydell1-6/+1
Change the highbank/midway boards to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit and start-powered-off properties on the CPU objects in the board code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with (in which case it will set these properties). This means that when running guest code at EL3, all the cores will start execution at once on poweron. This matches the real hardware behaviour. (A brief description of the hardware boot process is in the u-boot documentation for these boards: https://u-boot.readthedocs.io/en/latest/board/highbank/highbank.html#boot-process -- in theory one might run the 'a9boot'/'a15boot' secure monitor code in QEMU, though we probably don't emulate enough for that.) This affects the highbank and midway boards. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-10-peter.maydell@linaro.org
2022-02-08hw/arm/virt: Let boot.c handle PSCI enablementPeter Maydell1-11/+1
Instead of setting the CPU psci-conduit and start-powered-off properties in the virt board code, set the arm_boot_info psci_conduit field so that the boot.c code can do it. This will fix a corner case where we were incorrectly enabling PSCI emulation when booting guest code into EL3 because it was an ELF file passed to -kernel or to the generic loader. (EL3 guest code started via -bios or -pflash was already being run with PSCI emulation disabled.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-9-peter.maydell@linaro.org
2022-02-08hw/arm/versal: Let boot.c handle PSCI enablementPeter Maydell3-7/+5
Instead of setting the CPU psci-conduit and start-powered-off properties in the xlnx-versal-virt board code, set the arm_boot_info psci_conduit field so that the boot.c code can do it. This will fix a corner case where we were incorrectly enabling PSCI emulation when booting guest code into EL3 because it was an ELF file passed to -kernel. (EL3 guest code started via -bios, -pflash, or the generic loader was already being run with PSCI emulation disabled.) Note that EL3 guest code has no way to turn on the secondary CPUs because there's no emulated power controller, but this was already true for EL3 guest code run via -bios, -pflash, or the generic loader. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-8-peter.maydell@linaro.org
2022-02-08hw/arm/xlnx-zcu102: Don't enable PSCI conduit when booting guest in EL3Peter Maydell2-5/+7
Change the Xilinx ZynqMP-based board xlnx-zcu102 to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit property on the CPU objects in the SoC code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with. Note that this means that EL3 guest code will have no way to power on secondary cores, because we don't model any kind of power controller that does that on this SoC. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220127154639.2090164-7-peter.maydell@linaro.org
2022-02-08hw/arm: allwinner: Don't enable PSCI conduit when booting guest in EL3Peter Maydell2-5/+5
Change the allwinner-h3 based board to use the new boot.c functionality to allow us to enable psci-conduit only if the guest is being booted in EL1 or EL2, so that if the user runs guest EL3 firmware code our PSCI emulation doesn't get in its way. To do this we stop setting the psci-conduit property on the CPU objects in the SoC code, and instead set the psci_conduit field in the arm_boot_info struct to tell the common boot loader code that we'd like PSCI if the guest is starting at an EL that it makes sense with. This affects the orangepi-pc board. This commit leaves the secondary CPUs in the powered-down state if the guest is booting at EL3, which is the same behaviour as before this commit. The secondaries can no longer be started by that EL3 code making a PSCI call but can still be started via the CPU Configuration Module registers (which we model in hw/misc/allwinner-cpucfg.c). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-6-peter.maydell@linaro.org