aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
11 daysvhost_net: Rename vhost_set_vring_enable() for clarityLaurent Vivier4-6/+6
This is a cosmetic change with no functional impact. The function vhost_set_vring_enable() is specific to vhost_net and is used outside of vhost_net.c (specifically, in hw/net/virtio-net.c). To prevent confusion with other similarly named vhost functions, such as the one found in cryptodev-vhost.c, it has been renamed to vhost_net_set_vring_enable(). This clarifies that the function belongs to the vhost_net module. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
11 daysnet: Define net_client_set_link()Laurent Vivier3-14/+23
The code to set the link status is currently located in qmp_set_link(). This function identifies the device by name, searches for the corresponding NetClientState, and then updates the link status. In some parts of the code, such as vhost-user.c, the NetClientState are already available. Calling qmp_set_link() from these locations leads to a redundant search for the clients. This patch refactors the logic by introducing a new function, net_client_set_link(), which accepts a NetClientState array directly. qmp_set_link() is simplified to be a wrapper that performs the client search and then calls the new function. The vhost-user implementation is updated to use net_client_set_link() directly, thereby eliminating the unnecessary client lookup. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
11 daysnet: Refactor stream logic for reuse in '-net passt'Laurent Vivier4-219/+290
To prepare for the implementation of '-net passt', this patch moves the generic stream handling functions from net/stream.c into new net/stream_data.c and net/stream_data.h files. This refactoring introduces a NetStreamData struct that encapsulates the generic fields and logic previously in NetStreamState. The NetStreamState now embeds NetStreamData and delegates the core stream operations to the new generic functions. To maintain flexibility for different users of this generic code, callbacks for send and listen operations are now passed via function pointers within the NetStreamData struct. This allows callers to provide their own specific implementations while reusing the common connection and data transfer logic. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
11 daysvirtio-net: Add queues for RSS during migrationAkihiko Odaki3-16/+19
virtio_net_pre_load_queues() inspects vdev->guest_features to tell if VIRTIO_NET_F_RSS or VIRTIO_NET_F_MQ is enabled to infer the required number of queues. This works for VIRTIO_NET_F_MQ but it doesn't for VIRTIO_NET_F_RSS because only the lowest 32 bits of vdev->guest_features is set at the point and VIRTIO_NET_F_RSS uses bit 60 while VIRTIO_NET_F_MQ uses bit 22. Instead of inferring the required number of queues from vdev->guest_features, use the number loaded from the vm state. This change also has a nice side effect to remove a duplicate peer queue pair change by circumventing virtio_net_set_multiqueue(). Also update the comment in include/hw/virtio/virtio.h to prevent an implementation of pre_load_queues() from refering to any fields being loaded during migration by accident in the future. Fixes: 8c49756825da ("virtio-net: Add only one queue pair when realizing") Tested-by: Lei Yang <leiyang@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
11 daysnet: fix buffer overflow in af_xdp_umem_create()Anastasia Belova1-1/+1
s->pool has n_descs elements so maximum i should be n_descs - 1. Fix the upper bound. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: cb039ef3d9 ("net: add initial support for AF_XDP network backend") Cc: qemu-stable@nongnu.org Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Anastasia Belova <nabelova31@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
12 daysdocs/devel/tracing: Update trace.h creation rune to include SPDXPeter Maydell1-1/+1
checkpatch now checks that new files have an SPDX line. If you use the shell rune in tracing.rst to create a trace.h wrapper header, this triggers checkpatch to complain. Although these files are tiny, it's worth having the SPDX line to avoid having to add extra exception cases to checkpatch. Update the rune to include creating an SPDX line. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 dayshw/uefi: Create and use trace.h wrapper headerPeter Maydell5-4/+6
The documentation of the trace subsystem (docs/devel/tracing.rst) says that each subdirectory which uses trace events should create a wrapper trace.h file which includes the trace/trace-foo.h generated header, and that .c files then #include "trace.h". We didn't follow this pattern in hw/uefi/. Correct this by creating and using the trace.h wrapper header. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 daysdocs/system/target-i386: Remove the sentence about RHEL 7 being supportedThomas Huth1-3/+1
According to our "Supported build platforms" policy, RHEL 7 is not supported anymore, so let's remove the related sentence from the x86 documentation. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 daysaccel/kvm: Adjust the note about the minimum required kernel versionThomas Huth1-2/+1
Since commit 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and KVM_CAP_IOEVENTFD_ANY_LENGTH") we require at least kernel 4.5 to be able to use KVM. Adjust the upgrade_note accordingly. While we're at it, remove the text about kvm-kmod and the SourceForge URL since this is not actively maintained anymore. Fixes: 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and KVM_CAP_IOEVENTFD_ANY_LENGTH") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 daysdocs: remove repeated wordAndrew Kreimer1-1/+1
The word 'find' appears twice, remove the extra one. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 dayshw/usb/dev-hid: Support side and extra mouse buttons for usb-tabletThomas Lambertz1-3/+3
The necessary plumbing for side- and extra mouse buttons to reach usb-tablet is already done. But the descriptor advertises three buttons max. Increase this to 5. Buttons are now identical to usb-mouse. Signed-off-by: Thomas Lambertz <patch@thomaslambertz.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
12 daysMerge tag 'pull-tcg-20250711' of https://gitlab.com/rth7680/qemu into stagingStefan Hajnoczi12-33/+137
fpu: Process float_muladd_negate_result after rounding tcg: Use uintptr_t in tcg_malloc implementation linux-user: Hold the fd-trans lock across fork linux-user: Implement fchmodat2 syscall linux-user: Check for EFAULT failure in nanosleep linux-user: Use qemu_set_cloexec() to mark pidfd as FD_CLOEXEC linux-user/gen-vdso: Handle fseek() failure linux-user/gen-vdso: Don't read off the end of buf[] # -----BEGIN PGP SIGNATURE----- # # iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmhxSAkdHHJpY2hhcmQu # aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV9wiQf+PrXwKj+FusE0YU1y # Lnx6+S0M/lDRCNhbgBrw7JK5WUwIfnZQuepf0vjuhoHH1rUdT1EUYdJ7Quwj9fgG # 0YcKRD8OAVKNU8I3ydtzSaJ3TZ02nbbDbwGMoD/eNXGKx0Gt5907vD4PrjT+mByG # 6QTLwuql3ahkl/Tiskk2LwbmHRe0CXiezVuzgprbNiyxrgDT8ArqCq+VJzv/wb2O # 4t6BqRDvBzRe7MUUs2B2W+hs0HW4Rfqcye/3rRnYe7HA4CTiVNqY9rwgrQqGEO0P # 3Cf+VaF6CaLz+HuHfM8rz+xBhfo+UpZYOVMXk/7VEAG6geMKTcQG1tCJYhL+xklJ # 9r4ABw== # =rD+6 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Jul 2025 13:21:13 EDT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * tag 'pull-tcg-20250711' of https://gitlab.com/rth7680/qemu: linux-user: Use qemu_set_cloexec() to mark pidfd as FD_CLOEXEC tcg: Use uintptr_t in tcg_malloc implementation linux-user: Hold the fd-trans lock across fork linux-user/mips/o32: Drop sa_restorer functionality linux-user/gen-vdso: Don't read off the end of buf[] linux-user/gen-vdso: Handle fseek() failure linux-user: Check for EFAULT failure in nanosleep linux-user: Implement fchmodat2 syscall fpu: Process float_muladd_negate_result after rounding Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
12 daysMerge tag 'migration-20250711-pull-request' of ↵Stefan Hajnoczi24-321/+798
https://gitlab.com/farosas/qemu into staging Migration pull request - General cleanups around: postcopy, bg-snapshot, migration hooks, migration completion and formatting of 'info migrate'. - Overhaul of postcopy blocktime tracking. # -----BEGIN PGP SIGNATURE----- # # iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmhxGdgQHGZhcm9zYXNA # c3VzZS5kZQAKCRDHmNx0G+wxnahoD/9uNXirlmRk3tDnhiJsiYx+HnXYPFEORSZq # zlpUyqvhQ1POp3Fa5pRf+bJ5mmPw8h8PdOR2StMpnW2Xa1OatAZj5m1uityAVWOl # EkVfZLl0j6j9HCCmE3c4dztOGIBsd9YY0GWizL05XHYZPrdX4zOpolMN4m53RwQY # HUVD6T2y9eFDnCO6MsoA9EfmkFYCRvqlS0VzTcYzQFN4H+QHlcpDfweqJpTLPa+1 # trahAN9PBuMjoewjDqwkNkf0CLaCXHszAfj6yv62Vi8Cbp9DDPywIYJKFnxspElW # Fjg1b4MdsbYZNmeKgIawzgTOL1RrojvKkoi7KWp3D7M+/ZZl9kBwQuUcBXKI7N0R # Y0GNfkkTycn18nM0JU/6QWSuVeiPbLArxQUGP1cLgvcHSSNgD9JxWbNBu5+1fFOG # Gg3qnyYatJ6xJDiCrdKqV8fwozNlm/G6b9BiCDeVq+4nA2OKQ0shiNA1GZHvVSQL # X4uAPexETdHfA/LeA2w5sgVBEw7BewBdjLntZDIFsyBnLrvqrDcU5Aav0wiHoI8U # QBC2aIpJfMLHiIQ93mVX96NltXC7KvJTIZVl3iwfiYEYCvQtTYgdJ09ELXFJYxFX # XpTTazqpmPSfuZpPRgx9YbDP/kS8Fg/PTOlPeD0T/frFgd1S6Thh6OW455PavMp8 # ht2lE4sxjA== # =vtRD # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Jul 2025 10:04:08 EDT # 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-20250711-pull-request' of https://gitlab.com/farosas/qemu: (26 commits) migration: Rename save_live_complete_precopy_thread to save_complete_precopy_thread migration/postcopy: Add latency distribution report for blocktime migration/postcopy: blocktime allows track / report non-vCPU faults migration/postcopy: Optimize blocktime fault tracking with hashtable migration/postcopy: Cleanup the total blocktime accounting migration/postcopy: Cache the tid->vcpu mapping for blocktime migration/postcopy: Initialize blocktime context only until listen migration/postcopy: Report fault latencies in blocktime migration/postcopy: Add blocktime fault counts per-vcpu migration/postcopy: Bring blocktime layer to ns level migration/postcopy: Drop PostcopyBlocktimeContext.start_time migration/postcopy: Make all blocktime vars 64bits migration/postcopy: Drop all atomic ops in blocktime feature migration/postcopy: Push blocktime start/end into page req mutex migration: Add option to set postcopy-blocktime migration/postcopy: Avoid clearing dirty bitmap for postcopy too migration: Rewrite the migration complete detect logic migration/ram: Add tracepoints for ram_save_complete() migration/ram: One less indent for ram_find_and_save_block() migration: qemu_savevm_complete*() helpers ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
12 daysMerge tag 'pull-target-arm-20250711' of https://gitlab.com/pm215/qemu into ↵Stefan Hajnoczi62-2010/+4300
staging target-arm queue: * New board type max78000fthr * Enable use of CXL on Arm 'virt' board * Some more tidyup of ID register handling * Refactor AT insns and PMU regs into separate source files * Don't enforce NSE,NS check for EL3->EL3 returns * hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ * Allow nested-virtualization with KVM on the 'virt' board * system/qdev: Remove pointless NULL check in qdev_device_add_from_qdict * hw/arm/virt-acpi-build: Don't create ITS id mappings by default * target/arm: Remove unused helper_sme2_luti4_4b # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmhxEcoZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3j5yEACWYnNeqo8Yph6/EJExE6eV # r0tC6FBb5ShPgA6kDxhpOc1lI6uXGh8+D7bL9BePEdz/brCf1QDfs2Z4q/hb5ysX # D0H6VI5Gr1j6MjkFRBo3+vvYz4Yh++XLn5Q9lZv8zaSEdraq/ay2kxnuhRCK+4Ar # +QoGtKrGMJ7UCpfiRlvNnd1UjgORZf10EE/bRImX13sxeDomP3CZhFzAyJyShOP9 # JA7bAd4rYJ4oj8R33y8Yaxjwm4FOndj740B0zwpO8mpjzFiE5zbqsaO+mEgYSflc # OQisCu/KRFpyIR+UqP+4gNaJLfKQW5Y4r61zEaiJWV/c4RdKNnbK1f7MX11fNhOk # k1paF3GIXp6f794Hb14vtsYnKHF2eeNSmRkAomXxLgUSYzLezL+yj7cdYmRJhgYU # thc1PSiEmHYhjRmOaMC9+dkMtvIexWyDNYNFTygoOE5/kTMSazeTFQpFmw+ZuTee # 9pjKsYRZJgTa64IkJy1L34jc2gds48Q20KpQsqZ22KQcjwt4PW4eQXkvMylawSut # mArHVH6AAxIK+defeEmnQCJ0OccyGCENjRDuWyWMMGoP/ggZpO47rGWmCUOK8xz8 # IfGdPeF/9xsKSKWvjpiHyyKa48wuO2bVC+5bISS6IPA2uGneS2DpmjkHU+gHBqpk # GNlvEnXZfavZOHejE7/L/Q== # =hJ4/ # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Jul 2025 09:29:46 EDT # 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-20250711' of https://gitlab.com/pm215/qemu: (36 commits) tests/functional: Add a test for the MAX78000 arm machine docs/system: arm: Add max78000 board description target/arm: Remove helper_sme2_luti4_4b hw/arm/virt-acpi-build: Don't create ITS id mappings by default system/qdev: Remove pointless NULL check in qdev_device_add_from_qdict hw/arm/virt: Allow virt extensions with KVM hw/arm/arm_gicv3_kvm: Add a migration blocker with kvm nested virt target/arm: Enable feature ARM_FEATURE_EL2 if EL2 is supported target/arm/kvm: Add helper to detect EL2 when using KVM hw/arm: Allow setting KVM vGIC maintenance IRQ hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ target/arm: Don't enforce NSE,NS check for EL3->EL3 returns target/arm: Split out performance monitor regs to cpregs-pmu.c target/arm: Split out AT insns to tcg/cpregs-at.c target/arm: Drop stub for define_tlb_insn_regs arm/kvm: shorten one overly long line arm/cpu: store clidr into the idregs array arm/cpu: fix trailing ',' for SET_IDREG arm/cpu: store id_aa64afr{0,1} into the idregs array arm/cpu: store id_afr0 into the idregs array ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
12 daysMerge tag 'pull-request-2025-07-11' of https://gitlab.com/thuth/qemu into ↵Stefan Hajnoczi15-68/+227
staging * s390x: Allow to select different entries when booting via pxelinux.cfg * Link s390-ccw.img statically * Fix broken bamboo functional test * s390x code cleanups and refactorings # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCgAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmhw2i0RHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbUGtA//XVr5t2/iH+zFdaHHFglMtYkqwyYspa/O # zGPgcIZptQrzlbR+GFJwd4ae1HWb60E1YDyC7M1iWGQXeMNrDgeJJjUQfhB7693Y # CPT1FCWaqXdrTHQJhf5+EGJZopwY1K4EHs+bMxCpU3ManD+MKuXzCgOMzZATnPUZ # EcvOrzDBfEFEzQn5COUi5FF5Ds4DpOqQY1g1tpG92hQwWeAgdPPXSYlakG64Hm8C # Km6BzAcylrRiHdORk3GeMJ1cPQ3vCjMrjTd87ra/xuH+DvPeyZ31cRIWIP1dn44x # eog5dWo7pNmwfU50c4w/6dTSqwHG/bD/2ZPJH2nnJDLK02WeguantPN43fdoPU0c # NEMldVE5GAqEr7Sbd5YIw9lBqrROIDfeUAxje4VZa1gSY4N/GYMGEZaM5vqYJJTP # 0ndWP83QdamWuE0eOYMA+4oZiPpW79+Igv/PV13lsm9JgvO0WQisPFxE0cZqMTQp # +wgbQ69rpyMiQxpusiL/6LA3khDyC8Z8g7cmjBfpqgwmVAZp7ly+GLk+ctG0zsjE # hB99hkujZVkBZQLnVs0C/pXn1NdJ0wEupiHOSsVlQtqzNHlbweRJoxuGSp4Rl0Et # 0DnTr3YHB6bdvRazaKzlkBHLLAXKEw0/xaRWGbE4tftZIrkOEeE0LMLLaLWLNKhX # rqRoxq00OPs= # =SOH3 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Jul 2025 05:32:29 EDT # 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-07-11' of https://gitlab.com/thuth/qemu: target/s390x: Have s390_cpu_halt() not return anything target/s390x: Expose s390_count_running_cpus() method target/s390x: Remove unused s390_cpu_[un]halt() user stubs tests/functional/test_ppc_bamboo: Replace broken link with working assets tests/functional: Add dependency to the keymap_targets pc-bios: Update the s390 bios images with the pxelinux.cfg loadparm changes pc-bios/s390-ccw: link statically tests/functional: Add a test for s390x pxelinux.cfg network booting pc-bios/s390-ccw: Add a boot menu for booting via pxelinux.cfg pc-bios/s390-ccw: Make get_boot_index() from menu.c global pc-bios/s390-ccw: Allow up to 31 entries for pxelinux.cfg pc-bios/s390-ccw: Allow to select a different pxelinux.cfg entry via loadparm hw/s390x/s390-pci-bus.c: Use g_assert_not_reached() in functions taking an ett target/s390x/tcg: Use vaddr in s390_probe_access() target/s390x/kvm: Use vaddr in find/insert_hw_breakpoint() Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
12 daysMerge tag 'pull-loongarch-20250711' of https://github.com/bibo-mao/qemu into ↵Stefan Hajnoczi6-29/+26
staging loongarch queue # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQQNhkKjomWfgLCz0aQfewwSUazn0QUCaHCzhAAKCRAfewwSUazn # 0egkAP0eJcYWSaG1xH6Gevx/hGYthFhJrQ2IwMlTDHQsx8PAtQEArnm+nQ3+ckzN # 5ZHx7GR+hFTAy0WJSSndnLttYC1zsws= # =kcDz # -----END PGP SIGNATURE----- # gpg: Signature made Fri 11 Jul 2025 02:47:32 EDT # gpg: using EDDSA key 0D8642A3A2659F80B0B3D1A41F7B0C1251ACE7D1 # gpg: Good signature from "bibo mao <maobibo@loongson.cn>" [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: 7044 3A00 19C0 E97A 31C7 13C4 8E86 8FB7 A176 9D4C # Subkey fingerprint: 0D86 42A3 A265 9F80 B0B3 D1A4 1F7B 0C12 51AC E7D1 * tag 'pull-loongarch-20250711' of https://github.com/bibo-mao/qemu: target/loongarch: Remove unnecessary page size validity checking target/loongarch: Fix CSR STLBPS register write emulation target/loongarch: Correct spelling in helper_csrwr_pwcl() hw/intc/loongarch_extioi: Move unrealize function to common code Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
12 daysi386/cpu: Enable 0x1f leaf for YongFeng by defaultZhao Liu1-1/+5
Host YongFeng CPU has 0x1f leaf by default, so that enable it for Guest CPU by default as well. Suggested-by: Ewan Hai <ewanhai-oc@zhaoxin.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-10-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Enable 0x1f leaf for SapphireRapids by defaultZhao Liu1-1/+5
Host SapphireRapids CPU has 0x1f leaf by default, so that enable it for Guest CPU by default as well. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-9-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Enable 0x1f leaf for GraniteRapids by defaultZhao Liu1-1/+5
Host GraniteRapids CPU has 0x1f leaf by default, so that enable it for Guest CPU by default as well. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-8-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Enable 0x1f leaf for SierraForest by defaultZhao Liu1-0/+1
Host SierraForest CPU has 0x1f leaf by default, so that enable it for Guest CPU by default as well. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-7-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Enable 0x1f leaf for SierraForest by defaultZhao Liu1-1/+4
Host SierraForest CPU has 0x1f leaf by default, so that enable it for Guest CPU by default as well. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-7-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add a "x-force-cpuid-0x1f" propertyManish Mishra1-0/+1
Add a "x-force-cpuid-0x1f" property so that CPU models can enable it and have 0x1f CPUID leaf natually as the Host CPU. The advantage is that when the CPU model's cache model is already consistent with the Host CPU, for example, SRF defaults to l2 per module & l3 per package, 0x1f can better help users identify the topology in the VM. Adding 0x1f for specific CPU models should not cause any trouble in principle. This property is only enabled for CPU models that already have 0x1f leaf on the Host, so software that originally runs normally on the Host won't encounter issues in the Guest with corresponding CPU model. Conversely, some software that relies on checking 0x1f might have problems in the Guest due to the lack of 0x1f [*]. In summary, adding 0x1f is also intended to further emulate the Host CPU environment. [*]: https://lore.kernel.org/qemu-devel/PH0PR02MB738410511BF51B12DB09BE6CF6AC2@PH0PR02MB7384.namprd02.prod.outlook.com/ Signed-off-by: Manish Mishra <manish.mishra@nutanix.com> Co-authored-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> [Integrated and rebased 2 previous patches (ordered by post time)] Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Introduce cache model for YongFengEwan Hai1-0/+104
Add the cache model to YongFeng (v3) to better emulate its environment. Note, although YongFeng v2 was added after v10.0, it was also back ported to v10.0.2. Therefore, the new version (v3) is needed to avoid conflict. The cache model is as follows: --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x0 (0) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x8 (8) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 32768 (32 KB) --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x0 (0) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 65536 (64 KB) --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x0 (0) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x8 (8) number of sets = 0x200 (512) WBINVD/INVD acts on lower caches = false inclusive to lower caches = true complex cache indexing = false number of sets (s) = 512 (size synth) = 262144 (256 KB) --- cache 3 --- cache type = unified cache (3) cache level = 0x3 (3) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x0 (0) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x2000 (8192) WBINVD/INVD acts on lower caches = true inclusive to lower caches = true complex cache indexing = false number of sets (s) = 8192 (size synth) = 8388608 (8 MB) --- cache 4 --- cache type = no more caches (0) Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Ewan Hai <ewanhai-oc@zhaoxin.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-5-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Introduce cache model for SapphireRapidsZhao Liu1-0/+96
Add the cache model to SapphireRapids (v4) to better emulate its environment. The cache model is based on SapphireRapids-SP (Scalable Performance): --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0xc (12) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 49152 (48 KB) --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x8 (8) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 32768 (32 KB) --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x800 (2048) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 2048 (size synth) = 2097152 (2 MB) --- cache 3 --- cache type = unified cache (3) cache level = 0x3 (3) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x7f (127) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0xf (15) number of sets = 0x10000 (65536) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = true number of sets (s) = 65536 (size synth) = 62914560 (60 MB) --- cache 4 --- cache type = no more caches (0) Suggested-by: Tejus GK <tejus.gk@nutanix.com> Suggested-by: Jason Zeng <jason.zeng@intel.com> Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Reviewed-by: Tao Su <tao1.su@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-4-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Introduce cache model for GraniteRapidsZhao Liu1-0/+96
Add the cache model to GraniteRapids (v3) to better emulate its environment. The cache model is based on GraniteRapids-SP (Scalable Performance): --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0xc (12) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 49152 (48 KB) --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 65536 (64 KB) --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1 (1) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x800 (2048) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 2048 (size synth) = 2097152 (2 MB) --- cache 3 --- cache type = unified cache (3) cache level = 0x3 (3) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0xff (255) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x48000 (294912) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = true number of sets (s) = 294912 (size synth) = 301989888 (288 MB) --- cache 4 --- cache type = no more caches (0) Suggested-by: Tejus GK <tejus.gk@nutanix.com> Suggested-by: Jason Zeng <jason.zeng@intel.com> Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Reviewed-by: Tao Su <tao1.su@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Introduce cache model for SierraForestZhao Liu1-0/+96
Add the cache model to SierraForest (v3) to better emulate its environment. The cache model is based on SierraForest-SP (Scalable Performance): --- cache 0 --- cache type = data cache (1) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x8 (8) number of sets = 0x40 (64) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 64 (size synth) = 32768 (32 KB) --- cache 1 --- cache type = instruction cache (2) cache level = 0x1 (1) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x0 (0) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x8 (8) number of sets = 0x80 (128) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 128 (size synth) = 65536 (64 KB) --- cache 2 --- cache type = unified cache (3) cache level = 0x2 (2) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x7 (7) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0x10 (16) number of sets = 0x1000 (4096) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = false number of sets (s) = 4096 (size synth) = 4194304 (4 MB) --- cache 3 --- cache type = unified cache (3) cache level = 0x3 (3) self-initializing cache level = true fully associative cache = false maximum IDs for CPUs sharing cache = 0x1ff (511) maximum IDs for cores in pkg = 0x3f (63) system coherency line size = 0x40 (64) physical line partitions = 0x1 (1) ways of associativity = 0xc (12) number of sets = 0x24000 (147456) WBINVD/INVD acts on lower caches = false inclusive to lower caches = false complex cache indexing = true number of sets (s) = 147456 (size synth) = 113246208 (108 MB) --- cache 4 --- cache type = no more caches (0) Suggested-by: Tejus GK <tejus.gk@nutanix.com> Suggested-by: Jason Zeng <jason.zeng@intel.com> Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Reviewed-by: Tao Su <tao1.su@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711104603.1634832-2-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Use a unified cache_info in X86CPUStateZhao Liu2-128/+27
At present, all cases using the cache model (CPUID 0x2, 0x4, 0x80000005, 0x80000006 and 0x8000001D leaves) have been verified to be able to select either cache_info_intel or cache_info_amd based on the vendor. Therefore, further merge cache_info_intel and cache_info_amd into a unified cache_info in X86CPUState, and during its initialization, set different legacy cache models based on the vendor. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-19-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Select legacy cache model based on vendor in CPUID 0x8000001DZhao Liu1-5/+21
As preparation for merging cache_info_cpuid4 and cache_info_amd in X86CPUState, set legacy cache model based on vendor in the CPUID 0x8000001D leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as the default cache model like before, otherwise, select legacy Intel cache model (in cache_info_cpuid4). In fact, for Intel (and Zhaoxin) CPU, this change is safe because the extended CPUID level supported by Intel is up to 0x80000008. So Intel Guest doesn't have this 0x8000001D leaf. Although someone could bump "xlevel" up to 0x8000001D for Intel Guest, it's meaningless and this is undefined behavior. This leaf should be considered reserved, but the SDM does not explicitly state this. So, there's no need to specifically use vendor_cpuid_only_v2 to fix anything, as it doesn't even qualify as a fix since nothing is currently broken. Therefore, it is acceptable to select the default legacy cache model based on the vendor. For the CPUID 0x8000001D leaf, in X86CPUState, a unified cache_info is enough. It only needs to be initialized and configured with the corresponding legacy cache model based on the vendor. Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-18-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Select legacy cache model based on vendor in CPUID 0x80000006Zhao Liu1-5/+31
As preparation for merging cache_info_cpuid4 and cache_info_amd in X86CPUState, set legacy cache model based on vendor in the CPUID 0x80000006 leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as the default cache model like before, otherwise, select legacy Intel cache model (in cache_info_cpuid4). To ensure compatibility is not broken, add an enable_legacy_vendor_cache flag based on x-vendor-only-v2 to indicate cases where the legacy cache model should be used regardless of the vendor. For CPUID 0x80000006 leaf, enable_legacy_vendor_cache flag indicates to pick legacy Intel cache model, which is for compatibility with the behavior of PC machine v10.0 and older. The following explains how current vendor-based default legacy cache model ensures correctness without breaking compatibility. * For the PC machine v6.0 and older, vendor_cpuid_only=false, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model, and doesn't use legacy cache model (legacy_cache=false), then cache_info_cpuid4 and cache_info_amd are same, so 0x80000006 leaf uses its own cache model regardless of the vendor. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy AMD cache model just like their previous behavior. * For the PC machine v10.0 and older (to v6.1), vendor_cpuid_only=true, and vendor_cpuid_only_v2=false. - No change, since this leaf doesn't aware vendor_cpuid_only. * For the PC machine v10.1 and newer, vendor_cpuid_only=true, and vendor_cpuid_only_v2=true. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x80000006 leaf regardless of the vendor. Intel and Zhaoxin CPUs have their special encoding based on SDM, which is the expected behavior and no different from before. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is false, the legacy cache model is selected based on vendor. For AMD CPU, it will use legacy AMD cache as before. For non-AMD (Intel/Zhaoxin) CPU, it will use legacy Intel cache and be encoded based on SDM as expected. Here, selecting the legacy cache model based on the vendor does not change the previous (before the change) behavior. Therefore, the above analysis proves that, with the help of the flag enable_legacy_vendor_cache, it is acceptable to select the default legacy cache model based on the vendor. For the CPUID 0x80000006 leaf, in X86CPUState, a unified cache_info is enough. It only needs to be initialized and configured with the corresponding legacy cache model based on the vendor. Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-17-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Select legacy cache model based on vendor in CPUID 0x80000005Zhao Liu1-3/+32
As preparation for merging cache_info_cpuid4 and cache_info_amd in X86CPUState, set legacy cache model based on vendor in the CPUID 0x80000005 leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as the default cache model like before, otherwise, select legacy Intel cache model (in cache_info_cpuid4). To ensure compatibility is not broken, add an enable_legacy_vendor_cache flag based on x-vendor-only-v2 to indicate cases where the legacy cache model should be used regardless of the vendor. For CPUID 0x80000005 leaf, enable_legacy_vendor_cache flag indicates to pick legacy AMD cache model, which is for compatibility with the behavior of PC machine v10.0 and older. The following explains how current vendor-based default legacy cache model ensures correctness without breaking compatibility. * For the PC machine v6.0 and older, vendor_cpuid_only=false, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model, and doesn't use legacy cache model (legacy_cache=false), then cache_info_cpuid4 and cache_info_amd are same, so 0x80000005 leaf uses its own cache model regardless of the vendor. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy AMD cache model just like their previous behavior. * For the PC machine v10.0 and older (to v6.1), vendor_cpuid_only=true, and vendor_cpuid_only_v2=false. - No change, since this leaf doesn't aware vendor_cpuid_only. * For the PC machine v10.1 and newer, vendor_cpuid_only=true, and vendor_cpuid_only_v2=true. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x80000005 leaf regardless of the vendor. Only Intel CPUs have all-0 leaf due to vendor_cpuid_only_2=true, and this is exactly the expected behavior. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is false, the legacy cache model is selected based on vendor. For AMD CPU, it will use legacy AMD cache as expected. For Intel CPU, it will use legacy Intel cache but still get all-0 leaf due to vendor_cpuid_only_2=true as expected. (Note) And for Zhaoxin CPU, it will use legacy Intel cache model instead of AMD's. This is the difference brought by this change! But it's correct since then Zhaoxin could have the consistent cache info in CPUID 0x2, 0x4 and 0x80000005 leaves. Here, except Zhaoxin, selecting the legacy cache model based on the vendor does not change the previous (before the change) behavior. And the change for Zhaoxin is also a good improvement. Therefore, the above analysis proves that, with the help of the flag enable_legacy_vendor_cache, it is acceptable to select the default legacy cache model based on the vendor. For the CPUID 0x80000005 leaf, in X86CPUState, a unified cache_info is enough. It only needs to be initialized and configured with the corresponding legacy cache model based on the vendor. Cc: EwanHai <ewanhai-oc@zhaoxin.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-16-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Select legacy cache model based on vendor in CPUID 0x4Zhao Liu1-9/+34
As preparation for merging cache_info_cpuid4 and cache_info_amd in X86CPUState, set legacy cache model based on vendor in the CPUID 0x4 leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as the default cache model, otherwise, select legacy Intel cache model (in cache_info_cpuid4) as before. To ensure compatibility is not broken, add an enable_legacy_vendor_cache flag based on x-vendor-only-v2 to indicate cases where the legacy cache model should be used regardless of the vendor. For CPUID 0x4 leaf, enable_legacy_vendor_cache flag indicates to pick legacy Intel cache model, which is for compatibility with the behavior of PC machine v10.0 and older. The following explains how current vendor-based default legacy cache model ensures correctness without breaking compatibility. * For the PC machine v6.0 and older, vendor_cpuid_only=false, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model, and doesn't use legacy cache model (legacy_cache=false), then cache_info_cpuid4 and cache_info_amd are same, so 0x4 leaf uses its own cache model regardless of the vendor. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy Intel cache model just like their previous behavior. * For the PC machine v10.0 and older (to v6.1), vendor_cpuid_only=true, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x4 leaf regardless of the vendor. Only AMD CPUs have all-0 leaf due to vendor_cpuid_only=true, and this is exactly the behavior of these old machines. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy Intel cache model. Similarly, only AMD CPUs have all-0 leaf, and this is exactly the behavior of these old machines. * For the PC machine v10.1 and newer, vendor_cpuid_only=true, and vendor_cpuid_only_v2=true. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x4 leaf regardless of the vendor. And AMD CPUs have all-0 leaf. Nothing will change. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is false, the legacy cache model is selected based on vendor. For AMD CPU, it will use legacy AMD cache but still get all-0 leaf due to vendor_cpuid_only=true. For non-AMD (Intel/Zhaoxin) CPU, it will use legacy Intel cache as expected. Here, selecting the legacy cache model based on the vendor does not change the previous (before the change) behavior. Therefore, the above analysis proves that, with the help of the flag enable_legacy_vendor_cache, it is acceptable to select the default legacy cache model based on the vendor. For the CPUID 0x4 leaf, in X86CPUState, a unified cache_info is enough. It only needs to be initialized and configured with the corresponding legacy cache model based on the vendor. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-15-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Select legacy cache model based on vendor in CPUID 0x2Zhao Liu2-10/+38
As preparation for merging cache_info_cpuid4 and cache_info_amd in X86CPUState, set legacy cache model based on vendor in the CPUID 0x2 leaf. For AMD CPU, select legacy AMD cache model (in cache_info_amd) as the default cache model, otherwise, select legacy Intel cache model (in cache_info_cpuid4) as before. To ensure compatibility is not broken, add an enable_legacy_vendor_cache flag based on x-vendor-only-v2 to indicate cases where the legacy cache model should be used regardless of the vendor. For CPUID 0x2 leaf, enable_legacy_vendor_cache flag indicates to pick legacy Intel cache model, which is for compatibility with the behavior of PC machine v10.0 and older. The following explains how current vendor-based default legacy cache model ensures correctness without breaking compatibility. * For the PC machine v6.0 and older, vendor_cpuid_only=false, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model, and doesn't use legacy cache model (legacy_cache=false), then cache_info_cpuid4 and cache_info_amd are same, so 0x2 leaf uses its own cache model regardless of the vendor. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy Intel cache model just like their previous behavior. * For the PC machine v10.0 and older (to v6.1), vendor_cpuid_only=true, and vendor_cpuid_only_v2=false. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x2 leaf regardless of the vendor. Only AMD CPUs have all-0 leaf due to vendor_cpuid_only=true, and this is exactly the behavior of these old machines. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is true, they will use legacy Intel cache model. Similarly, only AMD CPUs have all-0 leaf, and this is exactly the behavior of these old machines. * For the PC machine v10.1 and newer, vendor_cpuid_only=true, and vendor_cpuid_only_v2=true. - If the named CPU model has its own cache model (legacy_cache=false), then cache_info_cpuid4 & cache_info_amd both equal to its own cache model, so it uses its own cache model in 0x2 leaf regardless of the vendor. And AMD CPUs have all-0 leaf. Nothing will change. - For max/host/named CPU (without its own cache model), then the flag enable_legacy_vendor_cache is false, the legacy cache model is selected based on vendor. For AMD CPU, it will use legacy AMD cache but still get all-0 leaf due to vendor_cpuid_only=true. For non-AMD (Intel/Zhaoxin) CPU, it will use legacy Intel cache as expected. Here, selecting the legacy cache model based on the vendor does not change the previous (before the change) behavior. Therefore, the above analysis proves that, with the help of the flag enable_legacy_vendor_cache, it is acceptable to select the default legacy cache model based on the vendor. For the CPUID 0x2 leaf, in X86CPUState, a unified cache_info is enough. It only needs to be initialized and configured with the corresponding legacy cache model based on the vendor. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-14-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add legacy_amd_cache_info cache modelZhao Liu1-59/+53
Based on legacy_l1d_cachei_amd, legacy_l1i_cache_amd, legacy_l2_cache_amd and legacy_l3_cache, build a complete legacy AMD cache model, which can clarify the purpose of these trivial legacy cache models, simplify the initialization of cache info in X86CPUState, and make it easier to handle compatibility later. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-13-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add legacy_intel_cache_info cache modelZhao Liu1-47/+54
Based on legacy_l1d_cache, legacy_l1i_cache, legacy_l2_cache and legacy_l3_cache, build a complete legacy intel cache model, which can clarify the purpose of these trivial legacy cache models, simplify the initialization of cache info in X86CPUState, and make it easier to handle compatibility later. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-12-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Fix CPUID[0x80000006] for Intel CPUZhao Liu1-4/+12
Per SDM, Intel supports CPUID[0x80000006]. But only L2 information is encoded in ECX (note that L2 associativity field encodings rules consistent with AMD are used), all other fields are reserved. Therefore, make the following changes to CPUID[0x80000006]: * Check the vendor in CPUID[0x80000006] and just encode L2 to ECX for Intel. * Drop the lines_per_tag assertion, since AMD supports this field but Intel doesn't. And this field can be easily checked via cpuid tool in Guest. * Apply the encoding change of Intel for Zhaoxin as well [1]. This fix also resolves the FIXME of legacy_l2_cache_amd: /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */ In addition, per AMD's APM, update the comment of CPUID[0x80000006]. [1]: https://lore.kernel.org/qemu-devel/c522ebb5-04d5-49c6-9ad8-d755b8998988@zhaoxin.com/ Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-11-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Rename AMD_ENC_ASSOC to X86_ENC_ASSOCZhao Liu1-8/+8
Rename AMD_ENC_ASSOC to X86_ENC_ASSOC since Intel also uses the same rules. While there are some slight differences between the rules in AMD APM v4.07 no.40332 and Intel. But considerring the needs of current QEMU, generally they are consistent and current AMD_ENC_ASSOC can be applied for Intel CPUs.. Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-10-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Mark CPUID[0x80000005] as reserved for IntelZhao Liu1-4/+8
Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current "assert" check blocks adding new cache model for non-AMD CPUs. And please note, although Zhaoxin mostly follows Intel behavior, this leaf is an exception [1]. So, with the compat property "x-vendor-cpuid-only-v2", for the machine since v10.1, check the vendor and encode this leaf as all-0 only for Intel CPU. In addition, drop lines_per_tag assertion in encode_cache_cpuid80000005(), since Zhaoxin will use legacy Intel cache model in this leaf - which doesn't have this field. This fix also resolves 2 FIXMEs of legacy_l1d_cache_amd and legacy_l1i_cache_amd: /*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */ In addition, per AMD's APM, update the comment of CPUID[0x80000005]. [1]: https://lore.kernel.org/qemu-devel/fa16f7a8-4917-4731-9d9f-7d4c10977168@zhaoxin.com/ Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-9-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add x-vendor-cpuid-only-v2 option for compatibilityZhao Liu3-1/+21
Add a compat property "x-vendor-cpuid-only-v2" (for PC machine v10.0 and older) to keep the original behavior. This property will be used to adjust vendor specific CPUID fields. Make x-vendor-cpuid-only-v2 depend on x-vendor-cpuid-only. Although x-vendor-cpuid-only and v2 should be initernal only, QEMU doesn't support "internal" property. To avoid any other unexpected issues, check the dependency. Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-8-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Drop CPUID 0x2 specific cache info in X86CPUStateZhao Liu2-21/+13
With the pre-defined cache model legacy_intel_cpuid2_cache_info, for X86CPUState there's no need to cache special cache information for CPUID 0x2 leaf. Drop the cache_info_cpuid2 field of X86CPUState and use the legacy_intel_cpuid2_cache_info directly. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-7-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Consolidate CPUID 0x4 leafZhao Liu1-11/+37
Modern Intel CPUs use CPUID 0x4 leaf to describe cache information and leave space in 0x2 for prefetch and TLBs (even TLB has its own leaf CPUID 0x18). And 0x2 leaf provides a descriptor 0xFF to instruct software to check cache information in 0x4 leaf instead. Therefore, follow this behavior to encode 0xFF when Intel CPU has 0x4 leaf with "x-consistent-cache=true" for compatibility. In addition, for older CPUs without 0x4 leaf, still enumerate the cache descriptor in 0x2 leaf, except the case that there's no descriptor matching the cache model, then directly encode 0xFF in 0x2 leaf. This makes sense, as in the 0x2 leaf era, all supported caches should have the corresponding descriptor. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-6-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Present same cache model in CPUID 0x2 & 0x4Zhao Liu3-2/+16
For a long time, the default cache models used in CPUID 0x2 and 0x4 were inconsistent and had a FIXME note from Eduardo at commit 5e891bf8fd50 ("target-i386: Use #defines instead of magic numbers for CPUID cache info"): "/*FIXME: CPUID leaf 2 descriptor is inconsistent with CPUID leaf 4 */". This difference is wrong, in principle, both 0x2 and 0x4 are used for Intel's cache description. 0x2 leaf is used for ancient machines while 0x4 leaf is a subsequent addition, and both should be based on the same cache model. Furthermore, on real hardware, 0x4 leaf should be used in preference to 0x2 when it is available. Revisiting the git history, that difference occurred much earlier. Current legacy_l2_cache_cpuid2 (hardcode: "0x2c307d"), which is used for CPUID 0x2 leaf, is introduced in commit d8134d91d9b7 ("Intel cache info, by Filip Navara."). Its commit message didn't said anything, but its patch [1] mentioned the cache model chosen is "closest to the ones reported in the AMD registers". Now it is not possible to check which AMD generation this cache model is based on (unfortunately, AMD does not use 0x2 leaf), but at least it is close to the Pentium 4. In fact, the patch description of commit d8134d91d9b7 is also a bit wrong, the original cache model in leaf 2 is from Pentium Pro, and its cache descriptor had specified the cache line size ad 32 byte by default, while the updated cache model in commit d8134d91d9b7 has 64 byte line size. But after so many years, such judgments are no longer meaningful. On the other hand, for legacy_l2_cache, which is used in CPUID 0x4 leaf, is based on Intel Core Duo (patch [2]) and Core2 Duo (commit e737b32a3688 ("Core 2 Duo specification (Alexander Graf).") The patches of Core Duo and Core 2 Duo add the cache model for CPUID 0x4, but did not update CPUID 0x2 encoding. This is the reason that Intel Guests use two cache models in 0x2 and 0x4 all the time. Of course, while no Core Duo or Core 2 Duo machines have been found for double checking, this still makes no sense to encode different cache models on a single machine. Referring to the SDM and the real hardware available, 0x2 leaf can be directly encoded 0xFF to instruct software to go to 0x4 leaf to get the cache information, when 0x4 is available. Therefore, it's time to clean up Intel's default cache models. As the first step, add "x-consistent-cache" compat option to allow newer machines (v10.1 and newer) to have the consistent cache model in CPUID 0x2 and 0x4 leaves. This doesn't affect the CPU models with CPUID level < 4 ("486", "pentium", "pentium2" and "pentium3"), because they have already had the special default cache model - legacy_intel_cpuid2_cache_info. [1]: https://lore.kernel.org/qemu-devel/5b31733c0709081227w3e5f1036odbc649edfdc8c79b@mail.gmail.com/ [2]: https://lore.kernel.org/qemu-devel/478B65C8.2080602@csgraf.de/ Cc: Alexander Graf <agraf@csgraf.de> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-5-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add default cache model for Intel CPUs with level < 4Zhao Liu1-0/+65
Old Intel CPUs with CPUID level < 4, use CPUID 0x2 leaf (if available) to encode cache information. Introduce a cache model "legacy_intel_cpuid2_cache_info" for the CPUs with CPUID level < 4, based on legacy_l1d_cache, legacy_l1i_cache, legacy_l2_cache_cpuid2 and legacy_l3_cache. But for L2 cache, this cache model completes self_init, sets, partitions, no_invd_sharing and share_level fields, referring legacy_l2_cache, to avoid someone increases CPUID level manually and meets assert() error. But the cache information present in CPUID 0x2 leaf doesn't change. This new cache model makes it possible to remove legacy_l2_cache_cpuid2 in X86CPUState and help to clarify historical cache inconsistency issue. Furthermore, apply this legacy cache model to all Intel CPUs with CPUID level < 4. This includes not only "pentium2" and "pentium3" (which have 0x2 leaf), but also "486" and "pentium" (which only have 0x1 leaf, and cache model won't be presented, just for simplicity). A legacy_intel_cpuid2_cache_info cache model doesn't change the cache information of the above CPUs, because they just depend on 0x2 leaf. Only when someone adjusts the min-level to >=4 will the cache information in CPUID leaf 4 differ from before: previously, the L2 cache information in CPUID leaf 0x2 and 0x4 was different, but now with legacy_intel_cpuid2_cache_info, the information they present will be consistent. This case almost never happens, emulating a CPUID that is not supported by the "ancient" hardware is itself meaningless behavior. Therefore, even though there's the above difference (for really rare case) and considering these old CPUs ("486", "pentium", "pentium2" and "pentium3") won't be used for migration, there's no need to add new versioned CPU models Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-4-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Add descriptor 0x49 for CPUID 0x2 encodingZhao Liu1-1/+12
The legacy_l2_cache (2nd-level cache: 4 MByte, 16-way set associative, 64 byte line size) corresponds to descriptor 0x49, but at present cpuid2_cache_descriptors doesn't support descriptor 0x49 because it has multiple meanings. The 0x49 is necessary when CPUID 0x2 and 0x4 leaves have the consistent cache model, and use legacy_l2_cache as the default L2 cache. Therefore, add descriptor 0x49 to represent general L2 cache. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Refine comment of CPUID2CacheDescriptorInfoZhao Liu1-9/+22
Refer to SDM vol.3 table 1-21, add the notes about the missing descriptor, and fix the typo and comment format. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-2-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/tdx: Don't mask off CPUID_EXT_PDCMXiaoyao Li1-1/+3
It gets below warning when booting TDX VMs: warning: TDX forcibly sets the feature: CPUID[eax=01h].ECX.pdcm [bit 15] Because CPUID_EXT_PDCM is fixed1 for TDX, and MSR_IA32_PERF_CAPABILITIES is supported for TDX guest unconditioanlly. Don't mask off CPUID_EXT_PDCM for TDX. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250625035710.2770679-1-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/tdx: Remove task->watch only when it's validXiaoyao Li1-1/+3
In some case (e.g., failed to connect to QGS socket), tdx_generate_quote_cleanup() is called with task->watch invalid. It triggers assertion of qemu-system-x86_64: GLib: g_source_remove: assertion 'tag > 0' failed Fix it by checking task->watch. Fixes: 40da501d8989 ("i386/tdx: handle TDG.VP.VMCALL<GetQuote>") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250625035505.2770580-1-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Unify family, model and stepping calculation for x86 CPUXiaoyao Li4-12/+38
There are multiple places where CPUID family/model/stepping info are retrieved from env->cpuid_version. Besides, the calculation of family and model inside host_cpu_vendor_fms() doesn't comply to what Intel and AMD define. For family, both Intel and AMD define that Extended Family ID needs to be counted only when (base) Family is 0xF. For model, Intel counts Extended Model when (base) Family is 0x6 or 0xF, while AMD counts EXtended MOdel when (base) Family is 0xF. Introduce generic helper functions to get family, model and stepping from the EAX value of CPUID leaf 1, with the correct calculation formula. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250630080610.3151956-5-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/kvm-cpu: Fix the indentation inside kvm_cpu_realizefn()Xiaoyao Li1-1/+1
The indentation of one of the } inside kvm_cpu_realizefn() isn'f correct. fix it. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250630080610.3151956-4-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386: Cleanup the usage of CPUID_VENDOR_INTEL_1Xiaoyao Li2-3/+3
There are code using "env->cpuid_vendor1 == CPUID_VENDOR_INTEL_1" to check if it is Intel vcpu. Cleanup them to just use IS_INTEL_CPU() Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250630080610.3151956-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
12 daysi386/cpu: Use CPUID_MODEL_ID_SZ instead of hardcoded 48Xiaoyao Li3-6/+6
There is already the MACRO CPUID_MODEL_ID_SZ defined in QEMU. Use it to replace all the hardcoded 48. Opportunistically fix the indentation of CPUID_VENDOR_SZ. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20250630080610.3151956-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2025-07-24 23:41:01 +0000