The migration stream on s390x contains data for the storage_attributes
which the analyze-migration.py cannot handle yet. Add the basic code
for handling this, so we can re-enable the check in the migration-test.
Message-ID: <20231120113951.162090-1-thuth@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>
QOM names currently don't have any enforced naming rules. This
can be problematic, e.g. when they are used on the command line
for the "-device" option (where the comma is used to separate
properties). To avoid that such problematic type names come in
again, let's restrict the set of acceptable characters during the
type registration.
Ideally, we'd apply here the same rules as for QAPI, i.e. all type
names should begin with a letter, and contain only ASCII letters,
digits, hyphen, and underscore. However, we already have so many
pre-existing types like:
486-x86_64-cpu
cfi.pflash01
power5+_v2.1-spapr-cpu-core
virt-2.6-machine
pc-i440fx-3.0-machine
... so that we have to allow "." and "+" for now, too. While the
dot is used in a lot of places, the "+" can fortunately be limited
to two classes of legacy names ("power" and "Sun-UltraSparc" CPUs).
We also cannot enforce the rule that names must start with a letter
yet, since there are lot of types that start with a digit. Still,
at least limiting the first characters to the alphanumerical range
should be way better than nothing.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231117114457.177308-6-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Type names should not contain special characters like ":" (so that
they are easier to use with QAPI and other parts). We are going to
forbid such names in an upcoming patch. Thus let's replace the ":"
here with a "-".
Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231117114457.177308-5-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Type names should not contain special characters like ":". Let's
remove the whole prefix here since it does not really seem to be
helpful to have such a prefix here. The type name is only used
internally for an interface type, so the renaming should not affect
the user interface or migration.
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231117114457.177308-4-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
QOM type names containing ',' result in awful UI. We got rid of them
in v6.0.0 (commit e178113ff6 hw: Replace anti-social QOM type names).
A few have crept back since:
xlnx,cframe-reg
xlnx,efuse
xlnx,pmc-efuse-cache
xlnx,versal-cfu-apb
xlnx,versal-cfu-fdro
xlnx,versal-cfu-sfr
xlnx,versal-crl
xlnx,versal-efuse
xlnx,zynqmp-efuse
These are all device types. They can't be plugged with -device /
device_add, except for "xlnx,efuse" (I'm not sure that one is
intentional).
They *can* be used with -device / device_add to request help.
Usability is poor, though: you have to double the comma, like this:
$ qemu-system-aarch64 -device xlnx,,pmc-efuse-cache,help
They can also be used with -global, where you must *not* double the
comma:
$ qemu-system-aarch64 -global xlnx,efuse.drive-index=2
Trap for the unwary.
"xlnx,efuse", "xlnx,versal-efuse", "xlnx,pmc-efuse-cache",
"xlnx-zynqmp-efuse" are from v6.2.0, "xlnx,versal-crl" is from v7.1.0,
and the remainder are new.
Rename them all to "xlnx-FOO", like commit e178113ff6 did.
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Message-ID: <20231117114457.177308-3-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Fixes: b65b4b7ae3 (xlnx-bbram: hw/nvram: Use dot in device type name)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[thuth: Use longhand syntax to avoid problems with the "." in the name]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20231117114457.177308-2-thuth@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
vCPU "reset" is only possible with system emulation.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20231212113640.30287-5-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231212113640.30287-4-philmd@linaro.org>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
mips_itu.c only requires declarations from "hw/core/cpu.h"
and "cpu.h". Avoid including the huge "exec/exec-all.h" header.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231212113640.30287-3-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231212113640.30287-2-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Outside of system emulation, only qtest_enabled() can be used.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231212113016.29808-3-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
"hw/core/cpu.h" declares 'first_cpu'. Include it to avoid
when unrelated headers are refactored:
system/qtest.c:548:33: error: use of undeclared identifier 'first_cpu'
address_space_write(first_cpu->as, addr, MEMTXATTRS_UNSPECIFIED,
^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231212113016.29808-2-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
These files are obviously related to Vmware emulation, so let's list
them in the corresponding section in the MAINTAINERS file.
Message-ID: <20231107102738.14797-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reduce atomicity while emitting opcodes, instead of later
during code generation. This ensures that any helper called
also sees the reduced atomicity requirement.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2034
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20231212193542.149117-1-richard.henderson@linaro.org>
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap.
Failure to do so results in incorrect memory exceptions to the guest.
Before 732d548732, this was implicitly done via truncation to
target_ulong but only in qemu-system-i386, not qemu-system-x86_64.
To fix this, we must add conditional zero-extensions.
Since we have to test for 32 vs 64-bit anyway, note that cs_base
is always zero in 64-bit mode.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
I noticed the code blocks where not rendering properly so thought I'd
better fix things up. So:
- Use better title for the machine type
- Explain why Xen is a little different
- Add a proper anchor to the tpm-device link
- add newline so code block properly renders
- add some indentation to make continuation clearer
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20231207130623.360473-1-alex.bennee@linaro.org>
The AioContext must be unlocked before calling blk_co_unref(), because
it takes the AioContext lock internally in blk_unref_bh(), which is
scheduled in the main thread. If we don't unlock, the AioContext is
locked twice and nested event loops such as in bdrv_graph_wrlock() will
deadlock.
Cc: <qemu-stable@nongnu.org>
Fixes: https://issues.redhat.com/browse/RHEL-15965
Fixes: 0c7d204f50
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20231208124352.30295-1-kwolf@redhat.com>
GUEST_VIRTIO_MMIO_* was added in Xen 4.17, so only define them
for CONFIG_XEN_CTRL_INTERFACE_VERSIONs up to 4.16.
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A misspelled condition in xen_native.h is hiding a bug in the enablement of
Xen for qemu-system-aarch64. The bug becomes apparent when building for
Xen 4.18.
While the i386 emulator provides the xenpv machine type for multiple architectures,
and therefore can be compiled with Xen enabled even when the host is Arm, the
opposite is not true: qemu-system-aarch64 can only be compiled with Xen support
enabled when the host is Arm.
Expand the computation of accelerator_targets['CONFIG_XEN'] similar to what is
already there for KVM.
Cc: Stefano Stabellini <stefano.stabellini@amd.com>
Cc: Richard W.M. Jones <rjones@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Reported-by: Michael Young <m.a.young@durham.ac.uk>
Fixes: 0c8ab1cddd ("xen_arm: Create virtio-mmio devices during initialization", 2023-08-30)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 7191f24c7f ("accel/kvm/kvm-all: Handle register access errors")
added error checking for KVM_SET_SREGS/KVM_SET_SREGS2. In doing so, it
exposed a long-running bug in current KVM support for SEV-ES where the
kernel assumes that MSR_EFER_LMA will be set explicitly by the guest
kernel, in which case EFER write traps would result in KVM eventually
seeing MSR_EFER_LMA get set and recording it in such a way that it would
be subsequently visible when accessing it via KVM_GET_SREGS/etc.
However, guest kernels currently rely on MSR_EFER_LMA getting set
automatically when MSR_EFER_LME is set and paging is enabled via
CR0_PG_MASK. As a result, the EFER write traps don't actually expose the
MSR_EFER_LMA bit, even though it is set internally, and when QEMU
subsequently tries to pass this EFER value back to KVM via
KVM_SET_SREGS* it will fail various sanity checks and return -EINVAL,
which is now considered fatal due to the aforementioned QEMU commit.
This can be addressed by inferring the MSR_EFER_LMA bit being set when
paging is enabled and MSR_EFER_LME is set, and synthesizing it to ensure
the expected bits are all present in subsequent handling on the host
side.
Ultimately, this handling will be implemented in the host kernel, but to
avoid breaking QEMU's SEV-ES support when using older host kernels, the
same handling can be done in QEMU just after fetching the register
values via KVM_GET_SREGS*. Implement that here.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: Lara Lazier <laramglazier@gmail.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Cc: <kvm@vger.kernel.org>
Fixes: 7191f24c7f ("accel/kvm/kvm-all: Handle register access errors")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20231206155821.1194551-1-michael.roth@amd.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUBfYMVl8eKPZB+73EuIgTA5dtgIFAmVurjcACgkQEuIgTA5d
tgLWVBAAkzus4nN2+Z0H23VUmeBPCLPFXRSkK8mOWC3ymbX3kiy/IjgM7Ept6QWA
btssTf3YEeDtycgbrb5GZ4kEfKThDN7bbGRHvCW5bjwkyLQN1Ys2K61CTRX0VhSi
U4HDE3gCm+LpO28BuV/1KunlSH4TWjt76AB6YG5PuyzSH+AbC8yY7m+VSJTmCw1k
cZv0TQ+9lqWc4C6ziETV8UqhhltBmd/57P3xFDKhYNl0EtzxnKGSZ2szzWqE7guY
DsmTlfB5bnkYPE51xxTcJnRj907utNrIfa2kbu9wXU/GuPuEf9QkDo1Dt3t1Z0Zm
OZPkloXC2eNufVcGYVJa2PylRjwFlg01IuhYmlhsgerg5LZz2RIyrWM61JTONF2J
6EvO89e2S3XpBbnl2ugf2rMIdW1tlLSWhnLZD+jZzOu+V2TeLm6/onHWCVQ02sLr
ddDVpf2djvUsmRvcBBYlI40FcC9Wt828Spm+wkRsGHC+VbAg2al6jRNXyJ2LWeiS
wGsAwRV6XhQz996uMOWTA7jEsAawHUFgYCsH4bgiqiWEn+FblufY2iicRxY4ZsJA
GXpvxGoUHWE8e0XjXG1BnRFo2Q5ns9SRl5gx5X7rcmIKUGGCh3ZI72zfeVgCjm7b
5/CV/YzKuCRWJCYcORguli1GVuPO01FJrBloTJc0OSaDAtZL2Mg=
=o2kr
-----END PGP SIGNATURE-----
Merge tag 'pull-ufs-20231205' of https://gitlab.com/jeuk20.kim/qemu into staging
ufs fixes for 8.2
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEUBfYMVl8eKPZB+73EuIgTA5dtgIFAmVurjcACgkQEuIgTA5d
# tgLWVBAAkzus4nN2+Z0H23VUmeBPCLPFXRSkK8mOWC3ymbX3kiy/IjgM7Ept6QWA
# btssTf3YEeDtycgbrb5GZ4kEfKThDN7bbGRHvCW5bjwkyLQN1Ys2K61CTRX0VhSi
# U4HDE3gCm+LpO28BuV/1KunlSH4TWjt76AB6YG5PuyzSH+AbC8yY7m+VSJTmCw1k
# cZv0TQ+9lqWc4C6ziETV8UqhhltBmd/57P3xFDKhYNl0EtzxnKGSZ2szzWqE7guY
# DsmTlfB5bnkYPE51xxTcJnRj907utNrIfa2kbu9wXU/GuPuEf9QkDo1Dt3t1Z0Zm
# OZPkloXC2eNufVcGYVJa2PylRjwFlg01IuhYmlhsgerg5LZz2RIyrWM61JTONF2J
# 6EvO89e2S3XpBbnl2ugf2rMIdW1tlLSWhnLZD+jZzOu+V2TeLm6/onHWCVQ02sLr
# ddDVpf2djvUsmRvcBBYlI40FcC9Wt828Spm+wkRsGHC+VbAg2al6jRNXyJ2LWeiS
# wGsAwRV6XhQz996uMOWTA7jEsAawHUFgYCsH4bgiqiWEn+FblufY2iicRxY4ZsJA
# GXpvxGoUHWE8e0XjXG1BnRFo2Q5ns9SRl5gx5X7rcmIKUGGCh3ZI72zfeVgCjm7b
# 5/CV/YzKuCRWJCYcORguli1GVuPO01FJrBloTJc0OSaDAtZL2Mg=
# =o2kr
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 04 Dec 2023 23:59:35 EST
# gpg: using RSA key 5017D831597C78A3D907EEF712E2204C0E5DB602
# gpg: Good signature from "Jeuk Kim <jeuk20.kim@samsung.com>" [unknown]
# gpg: aka "Jeuk Kim <jeuk20.kim@gmail.com>" [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: 5017 D831 597C 78A3 D907 EEF7 12E2 204C 0E5D B602
* tag 'pull-ufs-20231205' of https://gitlab.com/jeuk20.kim/qemu:
hw/ufs: avoid generating the same ID string for different LU devices
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
QEMU would not start when trying to create two UFS host controllers and
a UFS logical unit for each with the following options:
-device ufs,id=bus0 \
-device ufs-lu,drive=drive1,bus=bus0,lun=0 \
-device ufs,id=bus1 \
-device ufs-lu,drive=drive2,bus=bus1,lun=0 \
This is because the same ID string ("0:0:0/scsi-disk") is generated
for both UFS logical units.
To fix this issue, prepend the parent pci device's path to make
the ID string unique.
("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk")
Resolves: #2018
Fixes: 096434fea1 ("hw/ufs: Modify lu.c to share codes with SCSI subsystem")
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Jeuk Kim <jeuk20.kim@samsung.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20231204150543.48252-1-akinobu.mita@gmail.com>
Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
* Turn off SME if SVE is turned off (this combination doesn't
currently work and QEMU will assert if you try it)
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmVt3wQZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3vrmD/9zu48IxCdHFSshMRmXz6kI
tMvTrsMSOGXfuQqCbvLn3CUP/La50Yt/T1C2TKzVII1W8zpw8wEEvraCBjexzUzK
Jcjw0dPSIllQOHBkoUGsgqA0+UkhfIwH0po10rxm1L+ZP3DfISVdyDV9oxCNfEO0
pGXI1eAN9GIQtJtUj3kZE+RUoamJfoSjlm5XVeX3T+utEU7yf1461L1/qaylYOrW
wao72ffbuf41jRJwnVmMFoIPrwueYtEeuKl/EgYU4YPxkSQEo34u6d9fz2Irt6/Y
utO2SffhhmlxQaFhgPX3hvAsfapMt/p2Jy6oUpThOjN75adCq+g1CYj7lzEfIX16
kb2CY8zQ8NboJtgnkiQAA062myURnk/kmulv0OF6Hh0jHSuLzuMMLcCfBJgq4H6s
mnBCJfetwRgwqcSl1JTfrMm4wYOLmSrmOcM5JjYwY2YYjnFXI+XB1MdKm0h8cROG
nFu5TZtNnxgzqBgoh1140AYN851Y1dshczZIHb1/YuNpBIl+ZUO4v5sRT3KBSzb+
G21570neBv8QcfDSgrLesrjNBDREfkaWEu9BM85461uTjbCLG8RUpn+Jd4VtpkNe
YVzomhuM9CI5CmYdrTMJ74gnZUtAT9Q3FTcfGL8G4KiSIe85BTw+gEy4PhLXD6FT
68fP1M+s8/hsuXCJYbvmAA==
=K/u0
-----END PGP SIGNATURE-----
Merge tag 'pull-target-arm-20231204-1' of https://git.linaro.org/people/pmaydell/qemu-arm into staging
target-arm queue:
* Turn off SME if SVE is turned off (this combination doesn't
currently work and QEMU will assert if you try it)
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmVt3wQZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3vrmD/9zu48IxCdHFSshMRmXz6kI
# tMvTrsMSOGXfuQqCbvLn3CUP/La50Yt/T1C2TKzVII1W8zpw8wEEvraCBjexzUzK
# Jcjw0dPSIllQOHBkoUGsgqA0+UkhfIwH0po10rxm1L+ZP3DfISVdyDV9oxCNfEO0
# pGXI1eAN9GIQtJtUj3kZE+RUoamJfoSjlm5XVeX3T+utEU7yf1461L1/qaylYOrW
# wao72ffbuf41jRJwnVmMFoIPrwueYtEeuKl/EgYU4YPxkSQEo34u6d9fz2Irt6/Y
# utO2SffhhmlxQaFhgPX3hvAsfapMt/p2Jy6oUpThOjN75adCq+g1CYj7lzEfIX16
# kb2CY8zQ8NboJtgnkiQAA062myURnk/kmulv0OF6Hh0jHSuLzuMMLcCfBJgq4H6s
# mnBCJfetwRgwqcSl1JTfrMm4wYOLmSrmOcM5JjYwY2YYjnFXI+XB1MdKm0h8cROG
# nFu5TZtNnxgzqBgoh1140AYN851Y1dshczZIHb1/YuNpBIl+ZUO4v5sRT3KBSzb+
# G21570neBv8QcfDSgrLesrjNBDREfkaWEu9BM85461uTjbCLG8RUpn+Jd4VtpkNe
# YVzomhuM9CI5CmYdrTMJ74gnZUtAT9Q3FTcfGL8G4KiSIe85BTw+gEy4PhLXD6FT
# 68fP1M+s8/hsuXCJYbvmAA==
# =K/u0
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 04 Dec 2023 09:15:32 EST
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20231204-1' of https://git.linaro.org/people/pmaydell/qemu-arm:
target/arm: Disable SME if SVE is disabled
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
I missed this when going through the recent failure logs. I can run
the test 30 times without failure locally but it seems to hang pretty
reliably on GitLab's CI infra-structure.
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231201201027.2689404-1-alex.bennee@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
KVM_RISCV_GET_CSR() and KVM_RISCV_SET_CSR() use an 'int ret' variable
that is used to do an early 'return' if ret > 0. Both are being called
in functions that are also declaring a 'ret' integer, initialized with
'0', and this integer is used as return of the function.
The result is that the compiler is less than pleased and is pointing
shadowing errors:
../target/riscv/kvm/kvm-cpu.c: In function 'kvm_riscv_get_regs_csr':
../target/riscv/kvm/kvm-cpu.c:90:13: error: declaration of 'ret' shadows a previous local [-Werror=shadow=compatible-local]
90 | int ret = kvm_get_one_reg(cs, RISCV_CSR_REG(env, csr), ®); \
| ^~~
../target/riscv/kvm/kvm-cpu.c:539:5: note: in expansion of macro 'KVM_RISCV_GET_CSR'
539 | KVM_RISCV_GET_CSR(cs, env, sstatus, env->mstatus);
| ^~~~~~~~~~~~~~~~~
../target/riscv/kvm/kvm-cpu.c:536:9: note: shadowed declaration is here
536 | int ret = 0;
| ^~~
../target/riscv/kvm/kvm-cpu.c: In function 'kvm_riscv_put_regs_csr':
../target/riscv/kvm/kvm-cpu.c:98:13: error: declaration of 'ret' shadows a previous local [-Werror=shadow=compatible-local]
98 | int ret = kvm_set_one_reg(cs, RISCV_CSR_REG(env, csr), ®); \
| ^~~
../target/riscv/kvm/kvm-cpu.c:556:5: note: in expansion of macro 'KVM_RISCV_SET_CSR'
556 | KVM_RISCV_SET_CSR(cs, env, sstatus, env->mstatus);
| ^~~~~~~~~~~~~~~~~
../target/riscv/kvm/kvm-cpu.c:553:9: note: shadowed declaration is here
553 | int ret = 0;
| ^~~
The macros are doing early returns for non-zero returns and the local
'ret' variable for both functions is used just to do 'return 0', so
remove them from kvm_riscv_get_regs_csr() and kvm_riscv_put_regs_csr()
and do a straight 'return 0' in the end.
For good measure let's also rename the 'ret' variables in
KVM_RISCV_GET_CSR() and KVM_RISCV_SET_CSR() to '_ret' to make them more
resilient to these kind of errors.
Fixes: 937f0b4512 ("target/riscv: Implement kvm_arch_get_registers")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20231123101338.1040134-1-dbarboza@ventanamicro.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Using direct pointer dereferencing can allow for unaligned accesses,
which was seen during execution with sanitizers enabled.
Cc: qemu-stable@nongnu.org
Reviewed-by: Chris Rauer <crauer@google.com>
Reviewed-by: Peter Foley <pefoley@google.com>
Signed-off-by: Patrick Venture <venture@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-ID: <20231116163633.276671-1-venture@google.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
These variables "ret" are never referenced in the code, thus
add check logic for the "ret"
Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20231121080802.4500-1-zhujun2@cmss.chinamobile.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Replaces TABS with spaces to ensure have a consistent coding
style with an indentation of 4 spaces in the SH4 subsystem.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/376
Signed-off-by: Yihuan Pan <xun794@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20231124044554.513752-1-xun794@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Let's use 'unsupported_configs' and 'tested_configs' here
instead of non-inclusive words.
Message-ID: <20231122084000.809696-1-thuth@redhat.com>
Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
There is no architectural requirement that SME implies SVE, but
our implementation currently assumes it. (FEAT_SME_FA64 does
imply SVE.) So if you try to run a CPU with eg "-cpu max,sve=off"
you quickly run into an assert when the guest tries to write to
SMCR_EL1:
#6 0x00007ffff4b38e96 in __GI___assert_fail
(assertion=0x5555566e69cb "sm", file=0x5555566e5b24 "../../target/arm/helper.c", line=6865, function=0x5555566e82f0 <__PRETTY_FUNCTION__.31> "sve_vqm1_for_el_sm") at ./assert/assert.c:101
#7 0x0000555555ee33aa in sve_vqm1_for_el_sm (env=0x555557d291f0, el=2, sm=false) at ../../target/arm/helper.c:6865
#8 0x0000555555ee3407 in sve_vqm1_for_el (env=0x555557d291f0, el=2) at ../../target/arm/helper.c:6871
#9 0x0000555555ee3724 in smcr_write (env=0x555557d291f0, ri=0x555557da23b0, value=2147483663) at ../../target/arm/helper.c:6995
#10 0x0000555555fd1dba in helper_set_cp_reg64 (env=0x555557d291f0, rip=0x555557da23b0, value=2147483663) at ../../target/arm/tcg/op_helper.c:839
#11 0x00007fff60056781 in code_gen_buffer ()
Avoid this unsupported and slightly odd combination by
disabling SME when SVE is not present.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2005
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20231127173318.674758-1-peter.maydell@linaro.org
- gdbstub, properly halt when QEMU is having IO issues
- convert skipIf(GITLAB_CI) to skipUnless(QEMU_TEST_FLAKY_TESTS)
- tag sbsa-ref tests as TCG only
- build the correct microblaze for avocado-system-ubuntu
- add optional flaky tests job to CI
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmVqHFgACgkQ+9DbCVqe
KkQHLwgAjP2iL5LSa3FaMUoESJQqRB0rpoJ80gtEtmvmgRF0fHsRfHtDdMN9h2Ed
YilCDhMKLyr2ZoK4atyuc5SR6vCXI5RAvfTddex0xSxlvBX5Z5+1FMC6yA8SDJM7
ezEXACEKHiGv+l8gvOZOf9ZYEgh8DMJYFMbrtxuxKWw/kAjZ3R3X/ChCL94ZCPRe
486wqPIQfp5EPs2ddsW4DYFTjLpK5ImX+u/5kdaEGXwcg8UoLmQ9BVIrN/hYJ6u5
t/mAp1qVIQwSOSUBnerQ4ZkVQfCgLtEtiDtt8EZjUbQD3DcLjfHFjTwVlpqcC1zs
wHXYpLbD5jkthqav5E0DObCF9gIZdA==
=qtvU
-----END PGP SIGNATURE-----
Merge tag 'pull-more-8.2-fixes-011223-2' of https://gitlab.com/stsquad/qemu into staging
Flaky avocado tests, gdbstub and gitlab tweaks
- gdbstub, properly halt when QEMU is having IO issues
- convert skipIf(GITLAB_CI) to skipUnless(QEMU_TEST_FLAKY_TESTS)
- tag sbsa-ref tests as TCG only
- build the correct microblaze for avocado-system-ubuntu
- add optional flaky tests job to CI
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmVqHFgACgkQ+9DbCVqe
# KkQHLwgAjP2iL5LSa3FaMUoESJQqRB0rpoJ80gtEtmvmgRF0fHsRfHtDdMN9h2Ed
# YilCDhMKLyr2ZoK4atyuc5SR6vCXI5RAvfTddex0xSxlvBX5Z5+1FMC6yA8SDJM7
# ezEXACEKHiGv+l8gvOZOf9ZYEgh8DMJYFMbrtxuxKWw/kAjZ3R3X/ChCL94ZCPRe
# 486wqPIQfp5EPs2ddsW4DYFTjLpK5ImX+u/5kdaEGXwcg8UoLmQ9BVIrN/hYJ6u5
# t/mAp1qVIQwSOSUBnerQ4ZkVQfCgLtEtiDtt8EZjUbQD3DcLjfHFjTwVlpqcC1zs
# wHXYpLbD5jkthqav5E0DObCF9gIZdA==
# =qtvU
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 01 Dec 2023 12:48:08 EST
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [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: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-more-8.2-fixes-011223-2' of https://gitlab.com/stsquad/qemu:
gitlab: add optional job to run flaky avocado tests
gitlab: build the correct microblaze target
tests/avocado: tag sbsa tests as tcg only
docs/devel: rationalise unstable gitlab tests under FLAKY_TESTS
gdbstub: use a better signal when we halt for IO reasons
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The virtio-sound device is currently not migratable. QEMU crashes
on the source machine at some point during the migration with a
segmentation fault.
Even with this bug fixed, the virtio-sound device doesn't migrate
the state of the audio streams. For example, running streams leave
the device on the destination machine in a broken condition.
Mark the device as unmigratable until these issues have been fixed.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231204072837.6058-1-vr_qemu@t-online.de>
Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in
inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still
required, because it can happen that stream.avail_in becomes zero
before coming across a return value of Z_STREAM_END in the loop.
This fixes the host->guest direction of the clipboard with noVNC and
TigerVNC as clients.
Fixes: d921fea338 ("ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)")
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231122125826.228189-1-f.ebner@proxmox.com>
Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing
scanout") introduced a regression when QEMU is running with a
virtio-gpu-gl-device on a host under X11. After the guest has
initialized the virtio-gpu-gl-device, the guest screen only
shows "Display output is not active.".
Commit 6f189a08c1 moved all function calls in
gd_egl_scanout_texture() to a code path which is only called
once after gd_egl_init() succeeds in gd_egl_scanout_texture().
Move all function calls in gd_egl_scanout_texture() back to
the regular code path so they get always called if one of the
gd_egl_init() calls was successful.
Fixes: 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout")
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231111104020.26183-1-vr_qemu@t-online.de>
Keep it the same to vhost-user-blk.
At the same time, fix the vhost_reset_device.
Signed-off-by: Li Feng <fengli@smartx.com>
Message-Id: <20231123055431.217792-3-fengli@smartx.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
If the error occurs in vhost_dev_init, the value of s->connected is set to true
in advance, and there is no chance to enter this function execution again
in the future.
Signed-off-by: Li Feng <fengli@smartx.com>
Message-Id: <20231123055431.217792-2-fengli@smartx.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
