Log FIFO use (availability and depth).
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250220092903.3726-4-philmd@linaro.org>
Introduce 'fifo_depth' and 'fifo_available' local variables
to better express the 'r' variable use.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Luc Michel <luc.michel@amd.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250220092903.3726-3-philmd@linaro.org>
We shouldn't receive characters when the full UART or its
receiver is disabled. However we don't want to break the
possibly incomplete "my first bare metal assembly program"s,
so we choose to simply display a warning when this occurs.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Luc Michel <luc.michel@amd.com>
Message-Id: <20250220092903.3726-2-philmd@linaro.org>
Add description and set category for eTSEC device so it shows up
better in -device help.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20250218155407.838774E600E@zero.eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Message-Id: <20250218162618.46167-8-philmd@linaro.org>
Have "hw/xen/xen-bus" include the bare minimal set of headers.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Message-Id: <20250218162618.46167-7-philmd@linaro.org>
Have "hw/xen/xen-hvm-common.h" include the bare minimal set
of headers. Adapt sources to avoid errors when refactoring
unrelated headers such:
include/hw/xen/xen-hvm-common.h:71:5: error: unknown type name ‘xenevtchn_handle’
71 | xenevtchn_handle *xce_handle;
| ^~~~~~~~~~~~~~~~
hw/xen/xen-hvm-common.c: In function ‘cpu_get_ioreq’:
hw/xen/xen-hvm-common.c:227:13: error: implicit declaration of function ‘hw_error’
227 | hw_error("Fatal error while trying to get io event!\n");
| ^~~~~~~~
| herror
hw/xen/xen-hvm-common.c: In function ‘handle_ioreq’:
hw/xen/xen-hvm-common.c:446:34: error: ‘target_ulong’ undeclared (first use in this function)
446 | (req->size < sizeof (target_ulong))) {
| ^~~~~~~~~~~~
hw/i386/xen/xen-hvm.c: In function ‘xen_add_to_physmap’:
hw/i386/xen/xen-hvm.c:298:22: error: implicit declaration of function ‘xen_replace_cache_entry’
298 | uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size);
| ^~~~~~~~~~~~~~~~~~~~~~~
hw/i386/xen/xen-hvm.c:314:9: error: implicit declaration of function 'error_report' is invalid in C99
314 | error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx
^~~~~~~~~~~~
hw/i386/xen/xen-hvm.c: In function ‘xen_log_global_start’:
hw/i386/xen/xen-hvm.c:465:9: error: implicit declaration of function ‘xen_enabled’
465 | if (xen_enabled()) {
| ^~~~~~~~~~~
hw/i386/xen/xen-hvm.c: In function ‘regs_to_cpu’:
hw/i386/xen/xen-hvm.c:487:5: error: unknown type name ‘X86CPU’
487 | X86CPU *cpu;
| ^~~~~~
hw/i386/xen/xen-hvm.c:492:15: error: ‘R_EAX’ undeclared (first use in this function)
492 | env->regs[R_EAX] = req->data;
| ^~~~~
| REG_RAX
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Message-Id: <20250218162618.46167-6-philmd@linaro.org>
Have "hw/xen/xen-pvh-common.h" include the bare minimal set
of headers. Adapt sources to avoid errors when refactoring
unrelated headers such:
hw/i386/xen/xen-pvh.c: In function ‘xen_pvh_machine_class_init’:
hw/i386/xen/xen-pvh.c:84:28: error: ‘TARGET_DEFAULT_CPU_TYPE’ undeclared (first use in this function)
84 | mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
| ^~~~~~~~~~~~~~~~~~~~~~~
hw/xen/xen-pvh-common.c: In function ‘xen_pvh_init’:
hw/xen/xen-pvh-common.c:217:43: error: ‘MiB’ undeclared (first use in this function)
217 | if (s->cfg.pci_ecam.size != 256 * MiB) {
| ^~~
hw/xen/xen-hvm-common.c:18:6: error: no previous prototype for ‘xen_mr_is_memory’ [-Werror=missing-prototypes]
18 | bool xen_mr_is_memory(MemoryRegion *mr)
| ^~~~~~~~~~~~~~~~
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20250218162618.46167-5-philmd@linaro.org>
XenPVH requires the PCIe/GPEX device. Add it to Kconfig
to avoid when configuring using --without-default-devices:
/usr/bin/ld: libqemu-aarch64-softmmu.a.p/hw_xen_xen-pvh-common.c.o: in function `xenpvh_gpex_init':
hw/xen/xen-pvh-common.c:174: undefined reference to `gpex_set_irq_num'
/usr/bin/ld: libqemu-aarch64-softmmu.a.p/hw_xen_xen-hvm-common.c.o: in function `pci_dev_bus_num':
include/hw/pci/pci.h:337: undefined reference to `pci_bus_num'
/usr/bin/ld: include/hw/pci/pci.h:337: undefined reference to `pci_bus_num'
/usr/bin/ld: include/hw/pci/pci.h:337: undefined reference to `pci_bus_num'
/usr/bin/ld: include/hw/pci/pci.h:337: undefined reference to `pci_bus_num'
/usr/bin/ld: include/hw/pci/pci.h:337: undefined reference to `pci_bus_num'
/usr/bin/ld: libqemu-aarch64-softmmu.a.p/hw_xen_xen-hvm-common.c.o: in function `cpu_ioreq_config':
hw/xen/xen-hvm-common.c:412: undefined reference to `pci_host_config_read_common'
/usr/bin/ld: hw/xen/xen-hvm-common.c:428: undefined reference to `pci_host_config_read_common'
/usr/bin/ld: hw/xen/xen-hvm-common.c:438: undefined reference to `pci_host_config_write_common'
Fixes: f22e598a72 ("hw/xen: pvh-common: Add support for creating PCIe/GPEX")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20250218162618.46167-2-philmd@linaro.org>
Since the Virt machine is useless under Xen, do not even
try to build it there.
A Xen-only binary now only offers the XenPVH machine:
$ qemu-system-aarch64 -M help
Supported machines are:
none empty machine
xenpvh Xen PVH ARM machine
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20250218162618.46167-3-philmd@linaro.org>
acpi_ghes_memory_errors() is the only caller, no need to expose
the function. Besides, the last 'return' in this function isn't
necessary and remove it.
No functional changes intended.
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250214041635.608012-2-gshan@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Restrict the tb_flush() call to TCG. Assert we are using KVM or TCG.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Message-Id: <20250127102620.39159-3-philmd@linaro.org>
Apple defines a new "vmapple" machine type as part of its proprietary
macOS Virtualization.Framework vmm. This machine type is similar to the
virt one, but with subtle differences in base devices, a few special
vmapple device additions and a vastly different boot chain.
This patch reimplements this machine type in QEMU. To use it, you
have to have a readily installed version of macOS for VMApple,
run on macOS with -accel hvf, pass the Virtualization.Framework
boot rom (AVPBooter) in via -bios, pass the aux and root volume as pflash
and pass aux and root volume as virtio drives. In addition, you also
need to find the machine UUID and pass that as -M vmapple,uuid= parameter:
$ qemu-system-aarch64 -accel hvf -M vmapple,uuid=0x1234 -m 4G \
-bios /System/Library/Frameworks/Virtualization.framework/Versions/A/Resources/AVPBooter.vmapple2.bin
-drive file=aux,if=pflash,format=raw \
-drive file=root,if=pflash,format=raw \
-drive file=aux,if=none,id=aux,format=raw \
-device vmapple-virtio-blk-pci,variant=aux,drive=aux \
-drive file=root,if=none,id=root,format=raw \
-device vmapple-virtio-blk-pci,variant=root,drive=root
With all these in place, you should be able to see macOS booting
successfully.
Known issues:
- Currently only macOS 12 guests are supported. The boot process for
13+ will need further investigation and adjustment.
Signed-off-by: Alexander Graf <graf@amazon.com>
Co-authored-by: Phil Dennis-Jordan <phil@philjordan.eu>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-15-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This change addresses an edge case that trips up macOS guest drivers
for PCI based XHCI controllers. The guest driver would attempt to
schedule events to XHCI event rings 1 and 2 even when using PCI
pin-based interrupts. Interrupts would therefore be dropped, and events
only handled on timeout.
So, in addition to disabling interrupter mapping if numintrs is 1, a
callback is added to xhci to check whether interrupter mapping should be
enabled. The PCI XHCI device type now provides an implementation of
this callback if the new "conditional-intr-mapping" property is enabled.
(default: disabled) When enabled, interrupter mapping is only enabled
when MSI-X or MSI is active.
This means that when using pin-based interrupts, events are only
submitted to interrupter 0 regardless of selected target. This allows
the macOS guest drivers to work with the device in those configurations.
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2705
Message-ID: <20241227121336.25838-6-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Apple has its own virtio-blk PCI device ID where it deviates from the
official virtio-pci spec slightly: It puts a new "apple type"
field at a static offset in config space and introduces a new barrier
command.
This patch first creates a mechanism for virtio-blk downstream classes to
handle unknown commands. It then creates such a downstream class and a new
vmapple-virtio-blk-pci class which support the additional apple type config
identifier as well as the barrier command.
The 'aux' or 'root' device type are selected using the 'variant' property.
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20241223221645.29911-13-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Instead of device tree or other more standardized means, VMApple passes
platform configuration to the first stage boot loader in a binary encoded
format that resides at a dedicated RAM region in physical address space.
This patch models this configuration space as a qdev device which we can
then map at the fixed location in the address space. That way, we can
influence and annotate all configuration fields easily.
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-12-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The VMApple machine exposes AUX and ROOT block devices (as well as USB OTG
emulation) via virtio-pci as well as a special, simple backdoor platform
device.
This patch implements this backdoor platform device to the best of my
understanding. I left out any USB OTG parts; they're only needed for
guest recovery and I don't understand the protocol yet.
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-11-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
VMApple contains an "aes" engine device that it uses to encrypt and
decrypt its nvram. It has trivial hard coded keys it uses for that
purpose.
Add device emulation for this device model.
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-10-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
We will introduce a number of devices that are specific to the vmapple
target machine. To keep them all tidily together, let's put them into
a single target directory.
Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-7-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In addition to the ISA and PCI variants of pvpanic, let's add an MMIO
platform device that we can use in embedded arm environments.
Signed-off-by: Alexander Graf <graf@amazon.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-8-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The TYPE_ARM_GICV3 model doesn't have any particular
dependency on TCG, remove it. Rename the Kconfig selector
ARM_GICV3_TCG -> ARM_GICV3.
Fixes: a8a5546798 ("hw/intc/arm_gicv3: Introduce CONFIG_ARM_GIC_TCG Kconfig selector")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Message-Id: <20241227202435.48055-2-philmd@linaro.org>
When running checkpatch.pl on a commit adding a file without
SPDX tag we get:
Undefined subroutine &main::WARNING called at ./scripts/checkpatch.pl line 1694.
The WARNING level is reported by the WARN() method. Fix the typo.
Fixes: fa4d79c64d ("scripts: mandate that new files have SPDX-License-Identifier")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250303172508.93234-1-philmd@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* Fix a problem with the check-patch/check-dco CI jobs
* Replace the ppc64 e500 functional test with a better one
* Test retrieval of machine class properties
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAme+5TcRHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbUJZw//bgiGaTFI7Uzp7XgQyedVD5UJ6UiySNn8
58pEBjq8Q4gsFsckM4wp0BV3iRfy/EHncUd/bTTsBgrjF2T0+SBZFxkzO5Qw3l2U
5Qi158/9rteyKoTTz+WtlzbXY8hW7o2O0YriPwZDqAtWXXHGVOjTnXGqT3ZA6xM/
SV9q4ZzTjpSSpBq8UMSx2BkRaTsIQ2K9guDWYr1mTAOuP+AlzP5XRIcCyF4SuSzM
2VRCaGbHcHrZyyJP9D5JbRebIhwifl7OfXH/iaVpXRWot2pkRdA9zOv0Mxg/4qIl
VoUPBLxSIBov39i+9uVgBnwiBLObj+EU7T+qXJ1FoBe3WfjVaXEp6Nkj1/T3+Jn5
lKJGxgqX4xp7RvmLFQBS1/rA6buLco4H/IuUu1PgzGXtzZs78ZRLsC4cV8iMVKzi
0xFiK7nBxgYiSdDNMyh/kILwSB4zExhzGe40dz4MDyCThtDK1HZpuPRC4PiJAiH2
DlTT8O9uo9DVhwZqco1A0+m/Q2yCrF+wTte3AfB663RCjvYQKbRXUDYdu1hwC24K
6HQJ9M00FFM8H6YD3LY1bnN/wOTiuZ6zWcLP3bquOPIjmC0ogYkW054F3Mx+lmWk
3qOAjKOmznz7pTc+AvbX98FrKY58D2wJTuRjIMBWxFJQLOX/yIkQcfWPl3YPCT/a
AZf9kGVE2/g=
=KMhF
-----END PGP SIGNATURE-----
Merge tag 'pull-request-2025-02-26' of https://gitlab.com/thuth/qemu into staging
* Convert more avocado tests to the functional framework
* Fix a problem with the check-patch/check-dco CI jobs
* Replace the ppc64 e500 functional test with a better one
* Test retrieval of machine class properties
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAme+5TcRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbUJZw//bgiGaTFI7Uzp7XgQyedVD5UJ6UiySNn8
# 58pEBjq8Q4gsFsckM4wp0BV3iRfy/EHncUd/bTTsBgrjF2T0+SBZFxkzO5Qw3l2U
# 5Qi158/9rteyKoTTz+WtlzbXY8hW7o2O0YriPwZDqAtWXXHGVOjTnXGqT3ZA6xM/
# SV9q4ZzTjpSSpBq8UMSx2BkRaTsIQ2K9guDWYr1mTAOuP+AlzP5XRIcCyF4SuSzM
# 2VRCaGbHcHrZyyJP9D5JbRebIhwifl7OfXH/iaVpXRWot2pkRdA9zOv0Mxg/4qIl
# VoUPBLxSIBov39i+9uVgBnwiBLObj+EU7T+qXJ1FoBe3WfjVaXEp6Nkj1/T3+Jn5
# lKJGxgqX4xp7RvmLFQBS1/rA6buLco4H/IuUu1PgzGXtzZs78ZRLsC4cV8iMVKzi
# 0xFiK7nBxgYiSdDNMyh/kILwSB4zExhzGe40dz4MDyCThtDK1HZpuPRC4PiJAiH2
# DlTT8O9uo9DVhwZqco1A0+m/Q2yCrF+wTte3AfB663RCjvYQKbRXUDYdu1hwC24K
# 6HQJ9M00FFM8H6YD3LY1bnN/wOTiuZ6zWcLP3bquOPIjmC0ogYkW054F3Mx+lmWk
# 3qOAjKOmznz7pTc+AvbX98FrKY58D2wJTuRjIMBWxFJQLOX/yIkQcfWPl3YPCT/a
# AZf9kGVE2/g=
# =KMhF
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 26 Feb 2025 17:56:07 HKT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2025-02-26' of https://gitlab.com/thuth/qemu:
tests/functional: Replace the ppc64 e500 advent calendar test
gitlab: use --refetch in check-patch/check-dco jobs
tests/functional: Bump some arm test timeouts
tests/functional: Convert the x86_64 replay avocado tests
tests/functional: Convert the aarch64 replay avocado tests
tests/functional: Convert the s390x replay avocado tests
tests/functional: Convert the alpha replay avocado tests
tests/functional: Convert the arm replay avocado tests
tests/functional: Convert the m68k replay avocado tests
tests/functional: Convert the microblaze replay avocado tests
tests/functional: Convert the ppc64 replay avocado tests
tests/functional: Convert the or1k replay avocado tests
tests/functional: Convert the 32-bit ppc replay avocado tests
tests/functional: Convert the sparc replay avocado test
tests/functional: Convert the xtensa replay test to the functional framework
tests/functional: Provide a proper name for the VMs in the replay tests
tests/qtest/qom-test: Test retrieval of machine class properties
tests/functional: Have microblaze tests inherit common parent class
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
While SPDX-License-Identifier is a well known SPDX tag, there are a
great many more besides that[1]. These are mostly focused on making
machine readable metadata available to the 'reuse' tool and similar.
They cover concepts like author names, copyright owners, and much
more. It is even possible to define source file line groups and apply
different SPDX tags to regions of code within a file.
At this time we're only interested in adopting SPDX for recording the
file global licensing info, so detect & reject any other SPDX metadata.
If we want to explicitly collect extra data in SPDX format, we can
evaluate each data item on its merits when someone wants to propose it
at a later date.
[1] https://spdx.github.io/spdx-spec/v2.2.2/file-tags/https://spdx.github.io/spdx-spec/v2.2.2/file-information/
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We expect all new code to be contributed with the "GPL-2.0-or-later"
license tag. Divergence is permitted if the new file is derived from
pre-existing code under a different license, whether from elsewhere
in QEMU codebase, or outside.
Issue a warning if the declared license is not "GPL-2.0-or-later",
and an error if the license is not one of the handful of the
expected licenses to prevent unintended proliferation. The warning
asks users to explain their unusual choice of license in the commit
message.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Going forward we want all newly created source files to have an
SPDX-License-Identifier tag present.
Initially mandate this for C, Python, Perl, Shell source files,
as well as JSON (QAPI) and Makefiles, while encouraging users
to consider it for other file types.
Reviewed-by: Brian Cain <bcain@quicinc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
nvme_rw_complete_cb() is the only remaining user of nvme_aio_err(), so
open code the status code setting instead.
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The nvme_aio_err() does not handle Verify, Compare, Copy and other misc
commands and defaults to setting the error status code to Internal
Device Error. For some of these commands, we know better, so set it
explicitly.
For the commands using the nvme_misc_cb() callback (Copy, Flush, ...),
if no status code has explicitly been set by the lower handlers, default
to Internal Device Error as previously.
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The Command Abort Requested status code should only be set if the
command was explicitly cancelled due to an Abort command. Or, in the
case the cancel was due to Submission Queue deletion, set the status
code to Command Aborted due to SQ Deletion.
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The controller incorrectly allows a zoned namespace to be attached even
if CS.CSS is configured to only support the NVM command set for I/O
queues.
Rework handling of namespace command sets in general by attaching
supported namespaces when the controller is started instead of, like
now, statically when realized.
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
If the agent is set to daemonize but for whatever reason fails to
init the channel, the error message is lost. Worse, the agent
daemonizes needlessly and returns success. For instance:
# qemu-ga -m virtio-serial \
-p /dev/nonexistent_device \
-f /run/qemu-ga.pid \
-t /run \
-d
# echo $?
0
This makes it needlessly hard for init scripts to detect a
failure in qemu-ga startup. Though, they shouldn't pass '-d' in
the first place.
Let's open the channel first and only after that become a daemon.
Related bug: https://bugs.gentoo.org/810628
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <7a42b0cbda5c7e01cf76bc1b29a1210cd018fa78.1736261360.git.mprivozn@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Current logic on return value ('ret' variable) in main() is error
prone. The variable is initialized to EXIT_SUCCESS and then set
to EXIT_FAILURE on error paths. This makes it very easy to forget
to set the variable to indicate error when adding new error path,
as is demonstrated by handling of initialize_agent() failure.
It's simply lacking setting of the variable.
There's just one case where success should be indicated: when
dumping the config ('-D' cmd line argument).
To resolve this, initialize the variable to failure value and set
it explicitly to success value in that one specific case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <8a28265f50177a8dc4c10fcf4146e85a7fd748ee.1736261360.git.mprivozn@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20241216154552.213961-2-kkostiuk@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Zhaoxin CPUs (including vendors "Shanghai" and "Centaurhauls") handle the
CMPLegacy bit similarly to Intel CPUs. Therefore, this commit masks the
CMPLegacy bit in CPUID[0x80000001].ECX for Zhaoxin CPUs, just as it is done
for Intel CPUs.
AMD uses the CMPLegacy bit (CPUID[0x80000001].ECX.bit1) along with other CPUID
information to enumerate platform topology (e.g., the number of logical
processors per package). However, for Intel and other CPUs that follow Intel's
behavior, CPUID[0x80000001].ECX.bit1 is reserved.
- Impact on Intel and similar CPUs:
This change has no effect on Intel and similar CPUs, as the goal is to
accurately emulate CPU CPUID information.
- Impact on Linux Guests running on Intel (and similar) vCPUs:
During boot, Linux checks if the CPU supports Hyper-Threading. For the Linux
kernel before v6.9, if it detects X86_FEATURE_CMP_LEGACY, it assumes
Hyper-Threading is not supported. For Intel and similar vCPUs, if the
CMPLegacy bit is not masked in CPUID[0x80000001].ECX, Linux will incorrectly
assume that Hyper-Threading is not supported, even if the vCPU does support it.
Signed-off-by: EwanHai <ewanhai-oc@zhaoxin.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250113074413.297793-5-ewanhai-oc@zhaoxin.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Introduce support for the Zhaoxin Yongfeng CPU model.
The Zhaoxin Yongfeng CPU is Zhaoxin's latest server CPU.
This new cpu model ensure that QEMU can correctly emulate the Zhaoxin
Yongfeng CPU, providing accurate functionality and performance characteristics.
Signed-off-by: EwanHai <ewanhai-oc@zhaoxin.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250113074413.297793-4-ewanhai-oc@zhaoxin.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add new CPUID feature flags for various Zhaoxin PadLock extensions.
These definitions will be used for Zhaoxin CPU models.
Signed-off-by: EwanHai <ewanhai-oc@zhaoxin.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250113074413.297793-3-ewanhai-oc@zhaoxin.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Zhaoxin currently uses two vendors: "Shanghai" and "Centaurhauls".
It is important to note that the latter now belongs to Zhaoxin. Therefore,
this patch replaces CPUID_VENDOR_VIA with CPUID_VENDOR_ZHAOXIN1.
The previous CPUID_VENDOR_VIA macro was only defined but never used in
QEMU, making this change straightforward.
Additionally, the IS_ZHAOXIN_CPU macro has been added to simplify the
checks for Zhaoxin CPUs.
Signed-off-by: EwanHai <ewanhai-oc@zhaoxin.com>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20250113074413.297793-2-ewanhai-oc@zhaoxin.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Replace the advent calendar test with a buildroot image built with
qemu_ppc64_e5500_defconfig. Unlike the advent calendar image, this
newer buildroot image supports networking, too. Thus boot a ppce500
machine from kernel and disk, test network and poweroff.
Add '-no-shutdown' to the command line to avoid exiting from QEMU
as it seems to bother the functional framework.
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20250226065013.196052-1-clg@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[thuth: Add some wording about network support to the commit message]
Signed-off-by: Thomas Huth <thuth@redhat.com>
When gitlab initializes the repo checkout for a CI job, it will have
done a shallow clone with only partial history. Periodically the objects
that are omitted cause trouble with the check-patch/check-dco jobs. This
is exhibited as reporting strange errors being unable to fetch certain
objects that are known to exist.
Passing the --refetch flag to 'git fetch' causes it to not assume the
local checkout has all common objects and thus re-fetch everything that
is needed. This appears to solve the check-patch/check-dco job failures.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250225110525.2209854-1-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
On my local machine, for a debug build, sbsaref_alpine takes
nearly 900s:
$ (cd build/x86 && ./pyvenv/bin/meson test --setup thorough --suite func-thorough func-aarch64-aarch64_sbsaref_alpine
)
1/1 qemu:func-thorough+func-aarch64-thorough+thorough / func-aarch64-aarch64_sbsaref_alpine
OK 896.90s
arm_aspeed_rainier can also run close to its current timeout:
6/44 qemu:func-thorough+func-arm-thorough+thorough / func-arm-arm_aspeed_rainier
OK 215.75s
and arm_aspeed_ast2500 and arm_aspeed_ast2600 can go over:
13/44 qemu:func-thorough+func-arm-thorough+thorough / func-arm-arm_aspeed_ast2600
OK 792.94s
27/44 qemu:func-thorough+func-arm-thorough+thorough / func-arm-arm_aspeed_ast2500
TIMEOUT 480.01s
The sx1 test fails not on the overall meson timeout but on the
60 second timeout in some of the subtests.
Bump all these timeouts up a bit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250221140640.786341-1-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Put the tests into a separate file now (in the functional framework,
each file is run with one specific qemu-system-* binary).
Signed-off-by: Thomas Huth <thuth@redhat.com
Message-ID: <20250218152744.228335-14-thuth@redhat.com>
Put the tests into a separate file now (in the functional framework,
each file is run with one specific qemu-system-* binary).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250218152744.228335-13-thuth@redhat.com>
Put the tests into a separate file now (in the functional framework,
each file is run with one specific qemu-system-* binary).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250218152744.228335-12-thuth@redhat.com>
Put the tests into a separate file now (since in the functional
framework, each file is run with one specific qemu-system-* binary).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250218152744.228335-11-thuth@redhat.com>
Put the tests into a separate file now (since in the functional
framework, each file is run with one specific qemu-system-* binary).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250218152744.228335-10-thuth@redhat.com>
