aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2025-01-13hw: Replace DEVICE(object_new) -> qdev_new()Philippe Mathieu-Daudé2-3/+3
Prefer QDev API for QDev objects, avoid the underlying QOM layer. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20240216110313.17039-7-philmd@linaro.org>
2025-01-13target/arm: change default pauth algorithm to impdefPierrick Bouvier1-1/+3
Pointer authentication on aarch64 is pretty expensive (up to 50% of execution time) when running a virtual machine with tcg and -cpu max (which enables pauth=on). The advice is always: use pauth-impdef=on. Our documentation even mentions it "by default" in docs/system/introduction.rst. Thus, we change the default to use impdef by default. This does not affect kvm or hvf acceleration, since pauth algorithm used is the one from host cpu. This change is retro compatible, in terms of cli, with previous versions, as the semantic of using -cpu max,pauth-impdef=on, and -cpu max,pauth-qarma3=on is preserved. The new option introduced in previous patch and matching old default is -cpu max,pauth-qarma5=on. It is retro compatible with migration as well, by defining a backcompat property, that will use qarma5 by default for virt machine <= 9.2. Tested by saving and restoring a vm from qemu 9.2.0 into qemu-master (10.0) for cpus neoverse-n2 and max. Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241219183211.3493974-3-pierrick.bouvier@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-01-13hw/misc: cast rpm to uint64_tTigran Sogomonian1-2/+3
The value of an arithmetic expression 'rpm * NPCM7XX_MFT_PULSE_PER_REVOLUTION' is a subject to overflow because its operands are not cast to a larger data type before performing arithmetic. Thus, need to cast rpm to uint64_t. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Tigran Sogomonian <tsogomonian@astralinux.ru> Reviewed-by: Patrick Leis <venture@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Message-id: 20241226130311.1349-1-tsogomonian@astralinux.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-01-13hw/arm_sysctl: fix extracting 31th bit of valAnastasia Belova1-1/+1
1 << 31 is casted to uint64_t while bitwise and with val. So this value may become 0xffffffff80000000 but only 31th "start" bit is required. This is not possible in practice because the MemoryRegionOps uses the default max access size of 4 bytes and so none of the upper bytes of val will be set, but the bitfield extract API is clearer anyway. Use the bitfield extract() API instead. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Message-id: 20241220125429.7552-1-abelova@astralinux.ru Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: add clarification to commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-01-10Merge tag 'migration-20250110-pull-request' of ↵Stefan Hajnoczi1-1/+1
https://gitlab.com/farosas/qemu into staging Migration pull request - compression: Shameer's fix for CONFIG_UADK build Yuan Liu fixes for zero-page, QPL, qatzip - multifd sync cleanups, prereq. for VFIO and postcopy work - fixes for 9.2 regressions: multifd with pre-9.0 -> post-9.1 migrations (#2720) s390x migration (#2704) - fix for assertions during paused migrations; rework of late-block-activate logic (#2395, #686) - fixes for compressed arrays creation and parsing, mostly affecting s390x # -----BEGIN PGP SIGNATURE----- # # iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmeBDgkQHGZhcm9zYXNA # c3VzZS5kZQAKCRDHmNx0G+wxnSlUEACl31wY+77JxWnBva/eDDwnJ9HiCrqsoqaZ # YIJJXNlk4lYJWNdZRt6p27exzWrQwm+kWKPECeCakgCMlfhnKCvejGq7iV/fJY4o # D8hjE3t1htQ8mfblY1+bqzg3Rml59KwXxiqAwvlljbNWdkXruv026dq9vgJMzFhi # ia043fOO1tYULIoawgmwmLEHnztht0v+ZTZ1v5KQbrH655tpxls/8kHc6v5PXEpA # 3PSmCrCQh1dPtkYRjuJ9yHyfU+/T8tYwIjrU6VR1wQW7MBNkjtqNudaqAFiuyuqn # P8gh4rAQrMhA9y+aq6xSoJP8XGkuOHxLQtlNutlmtbcQyZ7JqgLmK9ZLdoPf21sK # //erV63NoyaciYB9Nk3NXflwroc6zyvo8A584kGNPwBznZOJLESP4SPvVm/nlE29 # vbyq8AWHRjFiqqf6P0ttQLAFkusZJzM1Y9UakF51hyVBX70yfqLG20XXZtIq/aZA # GbBB2Fo0MIlbmWaur3vLsSzn7B8d++Gl9TTGcK/eIXJ1ANCuCxGv9fbXJQlP5F4I # 3OAoSmAVJ2eqw4v0+2WMiEa8yUA5drNnDSI3VRkG+0K9jRfHKXki466/QQdGrNw7 # 8GuuzLBNai3gEKbavDU0Be73r982KjXeYXj7RuAkQfm0d4H7tiwtg91Cd1dPKfzh # mhpmOFJDCg== # =joNM # -----END PGP SIGNATURE----- # gpg: Signature made Fri 10 Jan 2025 07:09:45 EST # gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D # gpg: issuer "farosas@suse.de" # gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown] # gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D * tag 'migration-20250110-pull-request' of https://gitlab.com/farosas/qemu: (25 commits) multifd: bugfix for incorrect migration data with qatzip compression multifd: bugfix for incorrect migration data with QPL compression multifd: bugfix for migration using compression methods s390x: Fix CSS migration migration: Fix arrays of pointers in JSON writer migration: Dump correct JSON format for nullptr replacement migration: Rename vmstate_info_nullptr migration: Fix parsing of s390 stream migration: Remove unused argument in vmsd_desc_field_end migration: Add more error handling to analyze-migration.py migration/block: Rewrite disk activation migration/block: Fix possible race with block_inactive migration/block: Apply late-block-active behavior to postcopy migration/block: Make late-block-active the default qmp/cont: Only activate disks if migration completed migration: Add helper to get target runstate migration/multifd: Fix compat with QEMU < 9.0 migration/multifd: Document the reason to sync for save_setup() migration/multifd: Cleanup src flushes on condition check migration/multifd: Remove sync processing on postcopy ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-01-10Merge tag 'qom-qdev-20250109' of https://github.com/philmd/qemu into stagingStefan Hajnoczi8-14/+46
QOM & QDev patches - Remove DeviceState::opts (Akihiko) - Replace container_get by machine/object_get_container (Peter) - Remove InterfaceInfo::concrete_class field (Paolo) - Reduce machine_containers[] scope (Philippe) # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmeABNgACgkQ4+MsLN6t # wN4XtQ/+NyXEK9vjq+yXnk7LRxTDQBrXxNc71gLqNA8rGwXTuELIXOthNW+UM2a9 # CdnVbrIX/FRfQLXTHx0C2ENteafrR1oXDQmEOz1UeYgaCWJsNdVe3r1MYUdHcwVM # 90JcSbYhrvxFE/p/6WhTjjv2DXn4E8witsPwRc8EBi5bHeFz6cNPzhdF59A3ljZF # 0zr1MLHJHhwR6OoBbm9HM8x8i4Zw4LoKEjo8cCgcBfPQIMKf0HQ4XsinIDwn0VXN # S3jIysNyGHlptHOiJuErILZtzrm4F2lGwYan89jxuElfWjC7SVB2z4CQkQtPceIJ # HRBrE7VPwJ566OAThoSwPG3jXT1yCDOYmNCX1kJOMo9rYh3MwG0VrbMr5iwfYk8Z # wO+8IyMAx7m8FibdsoMmxtI1PYTf0JQaCB6MSwdoAMMQVp1FDWBun2g+swLjQgO4 # 15iSB+PMIZe7Ywd0b63VZrUMHKwMxd9RFYEbbsdA8DRI50W3HMQPZAJiGXt7RxJ9 # p9qxqg0WGpVjgTnInt/KH4axiWPD5cru+THVYk6dvOdtTM5wj2jEswWy2vQ6LkEF # MgxaUXfja8E20AXvdr6uXKwcKOIJ9+TaU5AhUmjpvacjJhy5eQdoFt9OnIMQt25U # KTtapCVsong5JzYZWhITNCMf5w2YGCJGJJekxdrqBvFk+FkMR38= # =+TLu # -----END PGP SIGNATURE----- # gpg: Signature made Thu 09 Jan 2025 12:18:16 EST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * tag 'qom-qdev-20250109' of https://github.com/philmd/qemu: system: Inline machine_containers[] in qemu_create_machine_containers() qom: remove unused InterfaceInfo::concrete_class field qom: Remove container_get() qom: Use object_get_container() qom: Add object_get_container() qdev: Use machine_get_container() qdev: Add machine_get_container() qdev: Make qdev_get_machine() not use container_get() qdev: Implement qdev_create_fake_machine() for user emulation qdev: Remove opts member hw/pci: Use -1 as the default value for rombar Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-01-09s390x: Fix CSS migrationFabiano Rosas1-1/+1
Commit a55ae46683 ("s390: move css_migration_enabled from machine to css.c") disabled CSS migration globally instead of doing it per-instance. CC: Paolo Bonzini <pbonzini@redhat.com> CC: qemu-stable@nongnu.org #9.1 Fixes: a55ae46683 ("s390: move css_migration_enabled from machine to css.c") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2704 Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20250109185249.23952-8-farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
2025-01-09qdev: Use machine_get_container()Peter Xu4-8/+6
Use machine_get_container() whenever applicable across the tree. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241121192202.4155849-11-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-01-09qdev: Add machine_get_container()Peter Xu1-0/+11
Add a helper to fetch machine containers. Add some sanity check around. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Xu <peterx@redhat.com> Message-ID: <20241121192202.4155849-10-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-01-09qdev: Make qdev_get_machine() not use container_get()Peter Xu1-1/+6
Currently, qdev_get_machine() has a slight misuse on container_get(), as the helper says "get a container" but in reality the goal is to get the machine object. It is still a "container" but not strictly. Note that it _may_ get a container (at "/machine") in our current unit test of test-qdev-global-props.c before all these changes, but it's probably unexpected and worked by accident. Switch to an explicit object_resolve_path_component(), with a side benefit that qdev_get_machine() can happen a lot, and we don't need to split the string ("/machine") every time. This also paves way for making the helper container_get() never try to return a non-container at all. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241121192202.4155849-9-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-01-09qdev: Implement qdev_create_fake_machine() for user emulationPhilippe Mathieu-Daudé2-0/+20
When a QDev instance is realized, qdev_get_machine() ends up called. In the next commit, qdev_get_machine() will require a "machine" container to be always present. To satisfy this QOM containers design, Implement qdev_create_fake_machine() which creates a fake "machine" container for user emulation. On system emulation, qemu_create_machine() is called from qemu_init(). For user emulation, since the TCG accelerator always calls tcg_init_machine(), we use it to hook our fake machine creation. Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20250102211800.79235-2-philmd@linaro.org>
2025-01-09qdev: Remove opts memberAkihiko Odaki1-1/+0
It is no longer used. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250104-reuse-v18-14-c349eafd8673@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-01-09hw/pci: Use -1 as the default value for rombarAkihiko Odaki2-4/+3
vfio_pci_size_rom() distinguishes whether rombar is explicitly set to 1 by checking dev->opts, bypassing the QOM property infrastructure. Use -1 as the default value for rombar to tell if the user explicitly set it to 1. The property is also converted from unsigned to signed. -1 is signed so it is safe to give it a new meaning. The values in [2 ^ 31, 2 ^ 32) become invalid, but nobody should have typed these values by chance. Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250104-reuse-v18-13-c349eafd8673@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-01-09Merge tag 'pull-xenfv-20250109-1' of https://gitlab.com/dwmw2/qemu into stagingStefan Hajnoczi4-25/+73
Xen emulation fixes # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEEMUsIrNDeSBEzpfKGm+mA/QrAFUQFAmd/qNYSHGR3bXdAYW1h # em9uLmNvLnVrAAoJEJvpgP0KwBVEtHsP/1qdpeVDCW1LAdGsOl9vixBXTR5/85G4 # m1KilpAPyxla8WfChRIagIdSAYGP5gN+yzbZ74AGb8HxumqJdl0bj6Gtqms2r8EQ # 4T7IU1iNONDkncApkHdQW9BdKg4Atq3dY8dEaN1UxzCfRjHC/KS5vHPN3OzGKqJ1 # tAk8wOcDtp7cfW+utw2ssjVR14cfJLQCR7/ehBfeFkC0DSd8p/yTJ31bFnLyPpBn # vh03MrslqV+h47D0uQxKwx5rtvNQhhIc/eRR/RymY3BSzAqRiyed/hTvsrRy4y/Z # EXB8ACQ6U2Ikrj//VXimSTx5aQDeGIU8nD6zvNRWZ1rTmTtD3n5dOxL2U9U5DBHb # TtlYhyochV6zO76mbINyjkSkGdj8ZZgF+5w5IIEhjazfHdWDuMdG0IjcRxl0r2Qz # 4jaoVjxMUT/MLI4noSVYFF29/aWYxsk/nsYCPOM2X4WuzK4/ragIWbpZZqOIFn4X # NyEc7xD2z9iL3MZe0Ygsa1eRpi/Gak0ih6W/u6ngON2EGESdF4T+CI+zTp6I4xtp # jOrAGltp6012pRJibHrKKdpnTYuQCRj3kSFAEP+JhNSBDUhbZ5lJWTnxiW7BkBO4 # BujmX3TMFsdt4jDqNQzht84Tgf4JEAYbGCks9msFcoYdZovKcyG3kgfZyAVfEap2 # kvCgGk7JMz1A # =5kvA # -----END PGP SIGNATURE----- # gpg: Signature made Thu 09 Jan 2025 05:45:42 EST # gpg: using RSA key 314B08ACD0DE481133A5F2869BE980FD0AC01544 # gpg: issuer "dwmw@amazon.co.uk" # gpg: Good signature from "David Woodhouse <dwmw@amazon.co.uk>" [unknown] # gpg: aka "David Woodhouse <dwmw@amazon.com>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 314B 08AC D0DE 4811 33A5 F286 9BE9 80FD 0AC0 1544 * tag 'pull-xenfv-20250109-1' of https://gitlab.com/dwmw2/qemu: hw/xen: Check if len is 0 before memcpy() hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-01-09hw/xen: Check if len is 0 before memcpy()Akihiko Odaki1-0/+4
data->data can be NULL when len is 0. Strictly speaking, the behavior of memcpy() in such a scenario is undefined so UBSan complaints. Satisfy UBSan by checking if len is 0 before memcpy(). Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
2025-01-09hw/i386/pc: Fix level interrupt sharing for Xen event channel GSIDavid Woodhouse3-25/+69
The system GSIs are not designed for sharing. One device might assert a shared interrupt with qemu_set_irq() and another might deassert it, and the level from the first device is lost. This could be solved by refactoring the x86 GSI code to use an OrIrq device, but that still wouldn't be ideal. The best answer would be to have a 'resample' callback which is invoked when the interrupt is acked at the interrupt controller, and causes the devices to re-trigger the interrupt if it should still be pending. This is the model that VFIO in Linux uses, with a 'resampler' eventfd that actually unmasks the interrupt on the hardware device and thus triggers a new interrupt from it if needed. As things stand, QEMU currently doesn't use that VFIO interface correctly, and just bashes on the resampler for every MMIO access to the device "just in case". Which requires unmapping and trapping the MMIO while an interrupt is pending! For the Xen callback GSI, QEMU does something similar — a flag is set which triggers a poll on *every* vmexst to see if the GSI should be deasserted. Proper resampler support would solve all of that, but is a task for later which has already been on the TODO list for a while. Since the Xen event channel GSI support *already* has hooks into the PC gsi_handler() code for routing GSIs to PIRQs, we can use that for a simpler bug fix. So... remember the externally-driven state of the line (from e.g. PCI INTx) and set the logical OR of that with the GSI. As a bonus, we now only need to enable the polling of vcpu_info on vmexit if the Xen callback GSI is the *only* reason the corresponding line is asserted. Closes: https://gitlab.com/qemu-project/qemu/-/issues/2731 Fixes: ddf0fd9ae1fd ("hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com>
2025-01-09hw/intc/loongarch_extioi: Add irq routing support from physical idBibo Mao1-4/+26
The simliar with IPI interrupt controller, physical cpu id is used for irq routing for extioi interrupt controller. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/intc/loongarch_extioi: Remove num-cpu propertyBibo Mao2-2/+0
Since cpu number can be acquired from possible_cpu_arch_ids(), num-cpu property is not necessary. Here remove num-cpu property for object TYPE_LOONGARCH_EXTIOI_COMMON object. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/intc/loongarch_extioi: Get cpu number from possible_cpu_arch_idsBibo Mao2-8/+15
Supported CPU number can be acquired from function possible_cpu_arch_ids(), cpu-num property is not necessary. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/loongarch/boot: Support Linux raw boot imageJiaxun Yang1-0/+69
Support booting such image by parsing header as per Linux's specification [1]. This enabled booting vmlinux.efi/vmlinuz.efi shipped by distros without supplying BIOS. [1]: https://docs.kernel.org/arch/loongarch/booting.html Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-09hw/core/loader: Use ssize_t for efi zboot unpackerJiaxun Yang2-3/+3
Convert to use sszie_t to represent size internally to avoid large image overflowing the size. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2025-01-07hw/s390x: Remove the "adapter_routes_max_batch" property from the flicThomas Huth2-12/+2
Now that the s390-ccw-virtio-2.8 machine has been removed, we don't need the "adapter_routes_max_batch" property anymore and can remove it. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-11-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine typeThomas Huth1-17/+0
The s390-ccw-virtio-2.8 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-10-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x: Remove the cpu_model_allowed flag and related codeThomas Huth1-8/+1
Now that the last machine type that disabled cpu_model_allowed has been removed, we can also remove the cpu_model_allowed flag itself and all the related conditional code. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-9-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine typeThomas Huth1-15/+0
The s390-ccw-virtio-2.7 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-8-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/css-bridge: Remove the "css_dev_path" propertyThomas Huth1-15/+1
Now that the s390-ccw-virtio-2.6 and older machine types have been removed, the "css_dev_path" property of the css-bridge is also not used anymore and thus can be removed. This way we finally get rid of the problem that has been described in: https://gitlab.com/qemu-project/qemu/-/issues/2213 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/ipl: Remove the "iplbext_migration" propertyThomas Huth2-11/+0
Now that the old machine types that used this property have been removed, we can remove the property and the corresponding code. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-6-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x: Remove the "ri_allowed" switchThomas Huth1-10/+4
Only s390-ccw-virtio-2.6 and older used to set this switch to "off", for newer machine types it is always enabled. Since we removed the old machine types now, we can also remove the switch in the code and assume that it is always enabled now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine typeThomas Huth1-20/+0
The s390-ccw-virtio-2.6 machine is older than 6 years, so according to our machine support policy, it can be removed now. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-4-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-skeys: Remove the "migration-enabled" propertyThomas Huth1-9/+1
This property was only set to "off" by the old s390-ccw-virtio-2.4 machine type which has now been removed. So we can now remove the property and the related code, too. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-3-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2025-01-07hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine typesThomas Huth1-37/+0
They are older than 6 years, so according to our machine support policy, they can be removed now. This removes the requirements for the storage keys "migration-enabled" property which will be removed in the next patch. It also removes the code that sets "max_revision" to 0 for some CCW devices, but the relating code in virtio-ccw.c indicates that 0 could have also been in use for other machines types < 5.1, so further clean-up for code related to "max_revision" won't be done yet (see also commit d55f518248f - "virtio: skip legacy support check on machine types less than 5.1"). Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Message-ID: <20250103144232.520383-2-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-31hw/display/qxl: Do not use C99 // commentsHyman Huang1-1/+1
Do not use C99 // comments to fix the checkpatch.pl error Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <7d287eaf00e0b52b600431efd350b15a0b5b3544.1734633496.git.yong.huang@smartx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/display/apple-gfx: Adds configurable mode listPhil Dennis-Jordan5-20/+141
This change adds a property 'display_modes' on the graphics device which permits specifying a list of display modes. (screen resolution and refresh rate) The property is an array of a custom type to make the syntax slightly less awkward to use, for example: -device '{"driver":"apple-gfx-pci", "display-modes":["1920x1080@60", "3840x2160@60"]}' 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-5-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/display/apple-gfx: Adds PCI implementationPhil Dennis-Jordan4-0/+157
This change wires up the PCI variant of the paravirtualised graphics device, mainly useful for x86-64 macOS guests, implemented by macOS's ParavirtualizedGraphics.framework. It builds on code shared with the vmapple/mmio variant of the PVG device. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20241223221645.29911-4-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework supportPhil Dennis-Jordan6-0/+1167
MacOS provides a framework (library) that allows any vmm to implement a paravirtualized 3d graphics passthrough to the host metal stack called ParavirtualizedGraphics.Framework (PVG). The library abstracts away almost every aspect of the paravirtualized device model and only provides and receives callbacks on MMIO access as well as to share memory address space between the VM and PVG. This patch implements a QEMU device that drives PVG for the VMApple variant of it. Signed-off-by: Alexander Graf <graf@amazon.com> Co-authored-by: Alexander Graf <graf@amazon.com> Subsequent changes: * Cherry-pick/rebase conflict fixes, API use updates. * Moved from hw/vmapple/ (useful outside that machine type) * Overhaul of threading model, many thread safety improvements. * Asynchronous rendering. * Memory and object lifetime fixes. * Refactoring to split generic and (vmapple) MMIO variant specific code. Implementation wise, most of the complexity lies in the differing threading models of ParavirtualizedGraphics.framework, which uses libdispatch and internal locks, versus QEMU, which heavily uses the BQL, especially during memory-mapped device I/O. Great care has therefore been taken to prevent deadlocks by never calling into PVG methods while holding the BQL, and similarly never acquiring the BQL in a callback from PVG. Different strategies have been used (libdispatch, blocking and non-blocking BHs, RCU, etc.) depending on the specific requirements at each framework entry and exit point. 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-3-phil@philjordan.eu> [PMD: Re-ordered imported headers, style fixups] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/usb/hcd-xhci: Unimplemented/guest error logging for port MMIOPhil Dennis-Jordan1-3/+22
The XHCI device code uses tracing rather than logging on various code paths that are so far unimplemented. In some cases, these code paths actually indicate faulty guest software. This patch switches instances in the read and write handlers for the port MMIO region to use qemu_log_mask() with LOG_UNIMP or LOG_GUEST_ERROR, as appropriate in each case. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241227121336.25838-5-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/usb/hcd-xhci-pci: Move msi/msix properties from NEC to superclassPhil Dennis-Jordan2-2/+6
The NEC XHCI controller exposes the underlying PCI device's msi and msix properties, but the superclass and thus the qemu-xhci device do not. There does not seem to be any obvious reason for this limitation. This change moves these properties to the superclass so they are exposed by both PCI XHCI device variants. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241227121336.25838-3-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/block/virtio-blk: Replaces request free function with g_freePhil Dennis-Jordan1-24/+19
The virtio_blk_free_request() function has been a 1-liner forwarding to g_free() for a while now. We may as well call g_free on the request pointer directly. 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-14-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/i386/amd_iommu: Simplify non-KVM checks on XTSup featurePhilippe Mathieu-Daudé1-9/+2
Generic code wanting to access KVM specific methods should do so being protected by the 'kvm_enabled()' helper. Doing so avoid link failures when optimization is disabled (using --enable-debug), see for example commits c04cfb4596a ("hw/i386: fix short-circuit logic with non-optimizing builds") and 0266aef8cd6 ("amd_iommu: Fix kvm_enable_x2apic link error with clang in non-KVM builds"). XTSup feature depends on KVM, so protect the whole block checking the XTSup feature with a check on whether KVM is enabled. Since x86_cpus_init() already checks APIC ID > 255 imply kernel support for irqchip and X2APIC, remove the confuse and unlikely reachable "AMD IOMMU xtsup=on requires support on the KVM side" message. Fix a type in "configuration" in error message. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20241129155802.35534-1-philmd@linaro.org>
2024-12-31hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'Philippe Mathieu-Daudé1-5/+5
Both QEMUResetHandler and FWCfgWriteCallback take an opaque pointer argument, no need to cast. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20241219153857.57450-3-philmd@linaro.org>
2024-12-31hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macroPhilippe Mathieu-Daudé1-11/+8
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20241219153857.57450-2-philmd@linaro.org>
2024-12-31fw_cfg: Don't set callback_opaque NULL in fw_cfg_modify_bytes_read()Shameer Kolothum1-1/+0
On arm/virt platform, Chen Xiang reported a Guest crash while attempting the below steps, 1. Launch the Guest with nvdimm=on 2. Hot-add a NVDIMM dev 3. Reboot 4. Guest boots fine. 5. Reboot again. 6. Guest boot fails. QEMU_EFI reports the below error: ProcessCmdAddPointer: invalid pointer value in "etc/acpi/tables" OnRootBridgesConnected: InstallAcpiTables: Protocol Error Debugging shows that on first reboot(after hot adding NVDIMM), Qemu updates the etc/table-loader len, qemu_ram_resize()   fw_cfg_modify_file()      fw_cfg_modify_bytes_read() And in fw_cfg_modify_bytes_read() we set the "callback_opaque" for the key entry to NULL. Because of this, on the second reboot, virt_acpi_build_update() is called with a NULL "build_state" and returns without updating the ACPI tables. This seems to be upsetting the firmware. To fix this, don't change the callback_opaque in fw_cfg_modify_bytes_read(). Fixes: bdbb5b1706d165 ("fw_cfg: add fw_cfg_machine_reset function") Reported-by: chenxiang <chenxiang66@hisilicon.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Message-ID: <20241203131806.37548-1-shameerali.kolothum.thodi@huawei.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/net/xilinx_ethlite: Rename rxbuf -> port_indexPhilippe Mathieu-Daudé1-6/+5
'rxbuf' is the index of the dual port RAM used. Rename it as 'port_index'. Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20241112181044.92193-8-philmd@linaro.org>
2024-12-31hw/net/xilinx_ethlite: Correct maximum RX buffer sizePhilippe Mathieu-Daudé1-1/+5
The current max RX bufsize is set to 0x800. This is invalid, since it contains the MMIO registers region. Add the correct definition (valid for both TX & RX, see datasheet p. 20, Table 11 "XPS Ethernet Lite MAC Memory Map") and use it. Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20241112181044.92193-6-philmd@linaro.org>
2024-12-31hw/net/xilinx_ethlite: Update QOM stylePhilippe Mathieu-Daudé1-26/+22
Use XlnxXpsEthLite typedef, OBJECT_DECLARE_SIMPLE_TYPE macro; convert type_init() to DEFINE_TYPES(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-Id: <20241112181044.92193-5-philmd@linaro.org>
2024-12-31hw/net/xilinx_ethlite: Remove unuseful debug logsPhilippe Mathieu-Daudé1-8/+0
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-Id: <20241112181044.92193-4-philmd@linaro.org>
2024-12-31hw/net/xilinx_ethlite: Convert some debug logs to trace eventsPhilippe Mathieu-Daudé2-2/+7
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-Id: <20241112181044.92193-3-philmd@linaro.org>
2024-12-31hw/sparc: Mark devices as big-endianPhilippe Mathieu-Daudé2-2/+2
These devices are only used by the SPARC targets, which are only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN definition expand to DEVICE_BIG_ENDIAN (besides, the DEVICE_LITTLE_ENDIAN case isn't tested). Simplify directly using DEVICE_BIG_ENDIAN. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241106184612.71897-6-philmd@linaro.org>
2024-12-31hw/openrisc: Mark devices as big-endianPhilippe Mathieu-Daudé2-2/+2
The openrisc little-endian control is in a control register: SR[LEE] (which we do not implement at present). These devices are only used by the OpenRISC target, which is only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN definition expand to DEVICE_BIG_ENDIAN (besides, the DEVICE_LITTLE_ENDIAN case isn't tested). Simplify directly using DEVICE_BIG_ENDIAN. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-Id: <20241106184612.71897-5-philmd@linaro.org>
2024-12-31hw/tricore: Mark devices as little-endianPhilippe Mathieu-Daudé1-1/+1
These devices are only used by the TriCore target, which is only built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN definition expand to DEVICE_LITTLE_ENDIAN (besides, the DEVICE_BIG_ENDIAN case isn't tested). Simplify directly using DEVICE_LITTLE_ENDIAN. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-Id: <20241106184612.71897-3-philmd@linaro.org>
generated by cgit v1.1 at 2025-04-14 15:21:18 +0000