ramfb: Add property to control if load the romfile
Currently the ramfb device loads the vgabios-ramfb.bin unconditionally,
but only the x86 need the vgabios-ramfb.bin, this can cause that when
use the release package on arm64 it can't find the vgabios-ramfb.bin.
Because only seabios will use the vgabios-ramfb.bin, load the rom logic
is x86-specific. For other !x86 platforms, the edk2 ships an EFI driver
for ramfb, so they don't need to load the romfile.
So add a new property use-legacy-x86-rom in both ramfb and vfio_pci
device, because the vfio display also use the ramfb_setup() to load
the vgabios-ramfb.bin file.
After have this property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
Message-ID: <20250717100941.2230408-2-shahuang@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
- update check-units script to take -n <top> argument
- fix execlog plugin to handle tab separators
- add gdb XML file for alpha
- add gdb XML file for sparc64
- use :kbd: in docs to highlight key sequences
- clean up rst formatting in virtio-net-failover docs
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmh0374ACgkQ+9DbCVqe
# KkR0gQf/a9Au455+OWEhG3uLGkMZZaFM6QJv8W3wBBZoRg59LMXkUIhEtyVfdmt5
# SDyA79nw1G0iP2qlKQV02R++CrBHMJILtYOMoLTbkWV9Lft4h+uPC27SE17DkNPS
# 4b4TchlJ3DpOFi0XmYZuIwH/8CPpTdVCLcA5zEXT0Q8nKjk0JsGiOQxoHH+p3ad5
# +mgvlmITDpU88OCilDYgmrD5iSe/WLzwszV9D6JTfQakfM7J9G87sj4iMK+En+iu
# 0rsRBk2gwahy4cfqaiaELTtarqadM1TaNwaRvt6vun+Hp12pypDhogG1Mh5e2eCB
# /nFwjcswRRk+kd26993AiK8Soomwiw==
# =Md3/
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 14 Jul 2025 06:45:18 EDT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* tag 'pull-10.1-rc0-maintainer-140725-1' of https://gitlab.com/stsquad/qemu:
gdbstub: add the GDB register XML files for sparc64.
docs/system: clean-up formatting of virtio-net-failover
docs: use :kbd: role in sphinx docs
plugins: fix inclusion of user-mode APIs
target/alpha: Add GDB XML feature file
contrib/plugins/execlog: Add tab to the separator search of insn_disas
gitlab: add -n option to check-units script
gitlab: use argparse in check-units script
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 14 Jul 2025 13:36:57 +0000 (09:36 -0400)]
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* rust: miscellaneous fixes
* rust: qemu-api-macros: cleanup and add unit tests for TryInto
* rust: log: implement io::Write, avoid memory allocations
when logging constant strings
* target/i386: fix usage of properties whenever accelerators
change the default (e.g. vendor)
* target/i386: add support for TDVMCALL_SETUP_EVENT_NOTIFY_INTERRUPT
* target/i386: add support for booting an SEV VM from an IGVM file
* target/i386: unify cache model descriptions between CPUID 2,
CPUID 4 and AMD specific CPUID 0x80000006
* target/i386: introduce cache models for recent Intel CPU models
* target/i386: mark some 0x80000000-0x80000008 bits as reserved on Intel
* target/i386: cleanups
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu: (77 commits)
i386/cpu: Honor maximum value for CPUID.8000001DH.EAX[25:14]
i386/cpu: Fix overflow of cache topology fields in CPUID.04H
i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]
i386/cpu: Reorder CPUID leaves in cpu_x86_cpuid()
tests/vm: bump FreeBSD image to 14.3
tests/functional: test_x86_cpu_model_versions: remove dead tests
i386/cpu: Mark CPUID 0x80000008 ECX bits[0:7] & [12:15] as reserved for Intel/Zhaoxin
i386/cpu: Mark CPUID 0x80000007[EBX] as reserved for Intel
i386/cpu: Mark EBX/ECX/EDX in CPUID 0x80000000 leaf as reserved for Intel
i386/cpu: Enable 0x1f leaf for YongFeng by default
i386/cpu: Enable 0x1f leaf for SapphireRapids by default
i386/cpu: Enable 0x1f leaf for GraniteRapids by default
i386/cpu: Enable 0x1f leaf for SierraForest by default
i386/cpu: Enable 0x1f leaf for SierraForest by default
i386/cpu: Add a "x-force-cpuid-0x1f" property
i386/cpu: Introduce cache model for YongFeng
i386/cpu: Introduce cache model for SapphireRapids
i386/cpu: Introduce cache model for GraniteRapids
i386/cpu: Introduce cache model for SierraForest
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 14 Jul 2025 13:36:18 +0000 (09:36 -0400)]
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
trivial patches for 2025-07-13
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmhzd4IACgkQgqpKJDse
# lHih7hAAyDGvYWAAmZex0+xq8Fwyvma0AenYSEWAeHEJLum/DP6KMF1z8o2cHZ/9
# uEImZXPv5xYTzNGK0KbE8H13R6nEI2sOh+Hh4SwBUoK9DQfu6VIY5fv3yPRZOD74
# HRd7acj4tovUbhaQHrlQAsftuat3gAIgPlMUEeISFeIOliC0MQqmWkZr58WSWHdo
# mnIhhOkMNwrALSr4z8qEK14dbDVI4Q49wKWz8lYWq1we8OBKnYuCphh9S+JIbq3w
# Z/wb4cGFocom1Vd6wjlQVeFGoFfoi++MRKHpDOpSyS11v+LWe/VL1KXbqIDMSoSZ
# 1uNMdU6r7y7ogxgZRMQGNaUuG2XM0imdUyVjCcF/TSLMlMQKv3TMApVoGhVgP3/x
# u1AZeiOc+nQK/ut89HhS2kXOrbaXQ4l3eroQK628xa+TQJSRUTW4ngJhwBQZB8G7
# NXBnMEHOVdgRK/1gFZ5jIuH/3BNBRFua3Nxo41B9hfevH8MhrZKXBu6TrYcNWjvM
# YHsPjOjjHLgSR582qRWVFEZZmTIbC80n5Jl8bI2AP/ZHBjAVGjRhMPzqZVm7rEik
# CrSGnKmBfT3GFqonu0f9/SouesO0W4du0jKA/Muz/XuUAhGJBUNDw/bT9AofUhVj
# iy8G/i8IRmpfvZmqNiB+OzfGGxYX3NJFENXC4FFBSYOhujNVJGw=
# =glYd
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 13 Jul 2025 05:08:18 EDT
# gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [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: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E
# Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478
* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
docs/devel/tracing: Update trace.h creation rune to include SPDX
hw/uefi: Create and use trace.h wrapper header
docs/system/target-i386: Remove the sentence about RHEL 7 being supported
accel/kvm: Adjust the note about the minimum required kernel version
docs: remove repeated word
hw/usb/dev-hid: Support side and extra mouse buttons for usb-tablet
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Alex Bennée [Thu, 10 Jul 2025 10:45:30 +0000 (11:45 +0100)]
docs/system: clean-up formatting of virtio-net-failover
We didn't clean-up the rst formatting when we moved this into the
docs so lets do that now:
- un-indent the usage/hotplug/migration paragraphs
- properly wrap the command line fragments in code-block
- highlight parameters in text with ``double quotes``
No changes to the actual text.
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250710104531.3099313-8-alex.bennee@linaro.org>
Sphinx supports the :kbd: role for notating keyboard input. They get
formatted as <kbd> HTML elements in the readthedocs theme we currently
use for Sphinx.
Besides the better visual formatting, it also helps with accessibility
as screen readers can announce the semantics of the <kbd> element to the
user.
Alex Bennée [Thu, 10 Jul 2025 10:45:28 +0000 (11:45 +0100)]
plugins: fix inclusion of user-mode APIs
In 903e870f24 (plugins/api: split out binary path/start/end/entry
code) we didn't actually enable the building of the new plugin helper.
However this was missed because only contrib plugins like drcov
actually used the helpers.
With that fixed we discover we also need some more includes to be able
to extract the relevant data from TaskState.
Fixes: 903e870f24 (plugins/api: split out binary path/start/end/entry code)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3014 Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250710104531.3099313-6-alex.bennee@linaro.org>
Yodel Eldar [Thu, 10 Jul 2025 10:45:26 +0000 (11:45 +0100)]
contrib/plugins/execlog: Add tab to the separator search of insn_disas
Currently, execlog searches for a space separator between the
instruction mnemonic and operands, but some disassemblers, e.g. Alpha's,
use a tab separator instead; this results in a null pointer being passed
as the haystack in g_strstr during a subsequent register search, i.e.
undefined behavior, because of a missing null check.
This patch adds tab to the separator search and a null check on the
result.
Also, an affected pointer is changed to const.
Lastly, a break statement was added to immediately terminate the
register search when a user-requested register is found in the current
instruction as a trivial optimization, because searching for the
remaining requested registers is unnecessary once one is found.
Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Yodel Eldar <yodel.eldar@gmail.com>
Message-ID: <20250630164124.26315-2-yodel.eldar@gmail.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250710104531.3099313-4-alex.bennee@linaro.org>
Zhao Liu [Mon, 14 Jul 2025 08:08:59 +0000 (16:08 +0800)]
i386/cpu: Honor maximum value for CPUID.8000001DH.EAX[25:14]
CPUID.8000001DH:EAX[25:14] is "NumSharingCache", and the number of
logical processors sharing this cache is the value of this field
incremented by 1. Because of its width limitation, the maximum value
currently supported is 4095.
Though at present Q35 supports up to 4096 CPUs, by constructing a
specific topology, the width of the APIC ID can be extended beyond 12
bits. For example, using `-smp threads=33,cores=9,modules=9` results in
a die level offset of 6 + 4 + 4 = 14 bits, which can also cause
overflow. Check and honor the maximum value as CPUID.04H did.
i386/cpu: Fix overflow of cache topology fields in CPUID.04H
According to SDM, CPUID.0x4:EAX[31:26] indicates the Maximum number of
addressable IDs for processor cores in the physical package. If we
launch over 64 cores VM, the 6-bit field will overflow, and the wrong
core_id number will be reported.
Since the HW reports 0x3f when the intel processor has over 64 cores,
limit the max value written to EAX[31:26] to 63, so max num_cores should
be 64.
For EAX[14:25], though at present Q35 supports up to 4096 CPUs, by
constructing a specific topology, the width of the APIC ID can be
extended beyond 12 bits. For example, using `-smp threads=33,cores=9,
modules=9` results in a die level offset of 6 + 4 + 4 = 14 bits, which
can also cause overflow. check and honor the maximum value for
EAX[14:25] as well.
In addition, for host-cache-info case, also apply the same checks and
fixes.
i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
The legacy topology enumerated by CPUID.1.EBX[23:16] is defined in SDM
Vol2:
Bits 23-16: Maximum number of addressable IDs for logical processors in
this physical package.
When threads_per_socket > 255, it will 1) overwrite bits[31:24] which is
apic_id, 2) bits [23:16] get truncated.
Specifically, if launching the VM with -smp 256, the value written to
EBX[23:16] is 0 because of data overflow. If the guest only supports
legacy topology, without V2 Extended Topology enumerated by CPUID.0x1f
or Extended Topology enumerated by CPUID.0x0b to support over 255 CPUs,
the return of the kernel invoking cpu_smt_allowed() is false and APs
(application processors) will fail to bring up. Then only CPU 0 is online,
and others are offline.
For example, launch VM via:
qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split \
-cpu qemu64,cpuid-0xb=off -smp 256 -m 32G \
-drive file=guest.img,if=none,id=virtio-disk0,format=raw \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=1 --nographic
i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]
When QEMU is started with:
-cpu host,migratable=on,host-cache-info=on,l3-cache=off
-smp 180,sockets=2,dies=1,cores=45,threads=2
On Intel platform:
CPUID.01H.EBX[23:16] is defined as "max number of addressable IDs for
logical processors in the physical package".
When executing "cpuid -1 -l 1 -r" in the guest, we obtain a value of 90 for
CPUID.01H.EBX[23:16], whereas the expected value is 128. Additionally,
executing "cpuid -1 -l 4 -r" in the guest yields a value of 63 for
CPUID.04H.EAX[31:26], which matches the expected result.
As (1+CPUID.04H.EAX[31:26]) rounds up to the nearest power-of-2 integer,
it's necessary to round up CPUID.01H.EBX[23:16] to the nearest power-of-2
integer too. Otherwise there would be unexpected results in guest with
older kernel.
For example, when QEMU is started with CLI above and xtopology is disabled,
guest kernel 5.15.120 uses CPUID.01H.EBX[23:16]/(1+CPUID.04H.EAX[31:26]) to
calculate threads-per-core in detect_ht(). Then guest will get "90/(1+63)=1"
as the result, even though threads-per-core should actually be 2.
And on AMD platform:
CPUID.01H.EBX[23:16] is defined as "Logical processor count". Current
result meets our expectation.
So round up CPUID.01H.EBX[23:16] to the nearest power-of-2 integer only
for Intel platform to solve the unexpected result.
Use the "x-vendor-cpuid-only-v2" compat option to fix this issue.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Guixiong Wei <weiguixiong@bytedance.com> Signed-off-by: Yipeng Yin <yinyipeng@bytedance.com> Signed-off-by: Chuang Xu <xuchuangxclwt@bytedance.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250714080859.1960104-5-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Sat, 12 Jul 2025 07:21:14 +0000 (09:21 +0200)]
tests/functional: test_x86_cpu_model_versions: remove dead tests
Tests that require machines older than 4.2 are now unconditionally skipped.
Remove them if they test legacy behavior, or use the latest machine if
they test current behavior.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, in QEMU, only ECX bits[0:7] and ECX bits[12:15] are encoded,
and both are emulated in QEMU.
Considering that Intel and Zhaoxin are already using the 0x1f leaf to
describe CPU topology, which includes similar information, Intel and
Zhaoxin will not implement ECX bits[0:7] and bits[12:15] of 0x80000008.
Therefore, mark these two fields as reserved and clear them for Intel
and Zhaoxin guests.
This commit adds support for the vhost-user interface to the passt
network backend, enabling high-performance, accelerated networking for
guests using passt.
The passt backend can now operate in a vhost-user mode, where it
communicates with the guest's virtio-net device over a socket pair
using the vhost-user protocol. This offloads the datapath from the
main QEMU loop, significantly improving network performance.
When the vhost-user=on option is used with -netdev passt, the new
vhost initialization path is taken instead of the standard
stream-based connection.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
This commit introduces support for passt as a new network backend.
passt is an unprivileged, user-mode networking solution that provides
connectivity for virtual machines by launching an external helper process.
The implementation reuses the generic stream data handling logic. It
launches the passt binary using GSubprocess, passing it a file
descriptor from a socketpair() for communication. QEMU connects to
the other end of the socket pair to establish the network data stream.
The PID of the passt daemon is tracked via a temporary file to
ensure it is terminated when QEMU exits.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
Introduce a boolean is_vhost_user field to the vhost_net
structure. This flag is initialized during vhost_net_init based
on whether the backend is vhost-user.
This refactoring simplifies checks for vhost-user specific behavior,
replacing direct comparisons of 'net->nc->info->type' with the new
flag. It improves readability and encapsulates the backend type
information directly within the vhost_net instance.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
net: Allow network backends to advertise max TX queue size
This commit refactors how the maximum transmit queue size for
virtio-net devices is determined, making the mechanism more generic
and extensible.
Previously, virtio_net_max_tx_queue_size() contained hardcoded
checks for specific network backend types (vhost-user and
vhost-vdpa) to determine their supported maximum queue size. This
created direct dependencies and would require modifications for
every new backend that supports variable queue sizes.
To improve flexibility, a new max_tx_queue_size field is added
to the vhost_net structure. This allows each network backend
to advertise its supported maximum transmit queue size directly.
The virtio_net_max_tx_queue_size() function now retrieves the max
TX queue size from the vhost_net struct, if available and set.
Otherwise, it defaults to VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
net: Add save_acked_features callback to vhost_net
This commit introduces a save_acked_features function pointer to
vhost_net and converts the vhost_net function into a generic dispatcher.
The vhost-user backend provides the callback, making its function static.
With this change, no other module has a direct dependency on the
vhost-user implementation.
This cleanup allows for the complete removal of the net/vhost-user.h
header file.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
net: Add get_acked_features callback to VhostNetOptions
This patch continues the effort to decouple the generic vhost layer
from specific network backend implementations.
Previously, the vhost_net initialization code contained a hardcoded
check for the vhost-user client type to retrieve its acked features
by calling vhost_user_get_acked_features(). This exposed an
internal vhost-user function in a public header and coupled the two
modules.
The vhost-user backend is updated to provide a callback, and its
getter function is now static. The call site in vhost_net.c is
simplified to use the new generic helper, removing the type check and
the direct dependency.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
net: Consolidate vhost feature bits into vhost_net structure
Previously, the vhost_net_get_feature_bits() function in
hw/net/vhost_net.c used a large switch statement to determine
the appropriate feature bits based on the NetClientDriver type.
This created unnecessary coupling between the generic vhost layer
and specific network backends (like TAP, vhost-user, and
vhost-vdpa).
This patch moves the definition of vhost feature bits directly into the
vhost_net structure for each relevant network client.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
The get_vhost_net() function previously contained a large switch
statement to find the VHostNetState pointer based on the net
client's type. This created a tight coupling, requiring the generic
vhost layer to be aware of every specific backend that supported
vhost, such as tap, vhost-user, and vhost-vdpa.
This approach is not scalable and requires modifying a central function
for any new backend. It also forced each backend to expose its internal
getter function in a public header file.
This patch refactors the logic by introducing a new get_vhost_net
function pointer to the NetClientInfo struct. The central
get_vhost_net() function is now a simple, generic dispatcher that
invokes the callback provided by the net client.
Each backend now implements its own private getter and registers it in
its NetClientInfo.
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
vhost_net: Rename vhost_set_vring_enable() for clarity
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>
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>
net: Refactor stream logic for reuse in '-net passt'
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>
Akihiko Odaki [Fri, 30 May 2025 05:18:53 +0000 (14:18 +0900)]
virtio-net: Add queues for RSS during migration
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>
Peter Maydell [Mon, 7 Jul 2025 14:49:17 +0000 (15:49 +0100)]
docs/devel/tracing: Update trace.h creation rune to include SPDX
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>
Peter Maydell [Mon, 7 Jul 2025 14:24:12 +0000 (15:24 +0100)]
hw/uefi: Create and use trace.h wrapper header
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>
Thomas Huth [Wed, 2 Jul 2025 08:21:38 +0000 (10:21 +0200)]
docs/system/target-i386: Remove the sentence about RHEL 7 being supported
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>
Thomas Huth [Wed, 2 Jul 2025 06:03:19 +0000 (08:03 +0200)]
accel/kvm: Adjust the note about the minimum required kernel version
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>
Andrew Kreimer [Sun, 15 Jun 2025 14:33:03 +0000 (17:33 +0300)]
docs: remove repeated word
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>
Thomas Lambertz [Mon, 12 May 2025 21:50:10 +0000 (23:50 +0200)]
hw/usb/dev-hid: Support side and extra mouse buttons for usb-tablet
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>
Stefan Hajnoczi [Sun, 13 Jul 2025 05:46:04 +0000 (01:46 -0400)]
Merge tag 'pull-tcg-20250711' of https://gitlab.com/rth7680/qemu into staging
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[]
* 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>
Stefan Hajnoczi [Sun, 13 Jul 2025 05:45:30 +0000 (01:45 -0400)]
Merge tag 'migration-20250711-pull-request' of 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>
Stefan Hajnoczi [Sun, 13 Jul 2025 05:45:17 +0000 (01:45 -0400)]
Merge tag 'pull-target-arm-20250711' of https://gitlab.com/pm215/qemu into 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
* 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>
Stefan Hajnoczi [Sun, 13 Jul 2025 05:44:51 +0000 (01:44 -0400)]
Merge tag 'pull-request-2025-07-11' of https://gitlab.com/thuth/qemu into 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
* 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>
Zhao Liu [Fri, 11 Jul 2025 10:46:02 +0000 (18:46 +0800)]
i386/cpu: Enable 0x1f leaf for SapphireRapids by default
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>
Zhao Liu [Fri, 11 Jul 2025 10:46:01 +0000 (18:46 +0800)]
i386/cpu: Enable 0x1f leaf for GraniteRapids by default
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>
Zhao Liu [Fri, 11 Jul 2025 10:46:00 +0000 (18:46 +0800)]
i386/cpu: Enable 0x1f leaf for SierraForest by default
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>
Zhao Liu [Fri, 11 Jul 2025 10:46:00 +0000 (18:46 +0800)]
i386/cpu: Enable 0x1f leaf for SierraForest by default
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>
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.
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>
Zhao Liu [Fri, 11 Jul 2025 10:45:57 +0000 (18:45 +0800)]
i386/cpu: Introduce cache model for SapphireRapids
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>
Zhao Liu [Fri, 11 Jul 2025 10:45:56 +0000 (18:45 +0800)]
i386/cpu: Introduce cache model for GraniteRapids
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>
Zhao Liu [Fri, 11 Jul 2025 10:45:55 +0000 (18:45 +0800)]
i386/cpu: Introduce cache model for SierraForest
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>
Zhao Liu [Fri, 11 Jul 2025 10:21:43 +0000 (18:21 +0800)]
i386/cpu: Use a unified cache_info in X86CPUState
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:42 +0000 (18:21 +0800)]
i386/cpu: Select legacy cache model based on vendor in CPUID 0x8000001D
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:41 +0000 (18:21 +0800)]
i386/cpu: Select legacy cache model based on vendor in CPUID 0x80000006
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:40 +0000 (18:21 +0800)]
i386/cpu: Select legacy cache model based on vendor in CPUID 0x80000005
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:39 +0000 (18:21 +0800)]
i386/cpu: Select legacy cache model based on vendor in CPUID 0x4
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:38 +0000 (18:21 +0800)]
i386/cpu: Select legacy cache model based on vendor in CPUID 0x2
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:37 +0000 (18:21 +0800)]
i386/cpu: Add legacy_amd_cache_info cache model
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:36 +0000 (18:21 +0800)]
i386/cpu: Add legacy_intel_cache_info cache model
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:35 +0000 (18:21 +0800)]
i386/cpu: Fix CPUID[0x80000006] for Intel CPU
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].
Zhao Liu [Fri, 11 Jul 2025 10:21:34 +0000 (18:21 +0800)]
i386/cpu: Rename AMD_ENC_ASSOC to X86_ENC_ASSOC
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..
Zhao Liu [Fri, 11 Jul 2025 10:21:33 +0000 (18:21 +0800)]
i386/cpu: Mark CPUID[0x80000005] as reserved for Intel
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].
Zhao Liu [Fri, 11 Jul 2025 10:21:32 +0000 (18:21 +0800)]
i386/cpu: Add x-vendor-cpuid-only-v2 option for compatibility
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:31 +0000 (18:21 +0800)]
i386/cpu: Drop CPUID 0x2 specific cache info in X86CPUState
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:30 +0000 (18:21 +0800)]
i386/cpu: Consolidate CPUID 0x4 leaf
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:29 +0000 (18:21 +0800)]
i386/cpu: Present same cache model in CPUID 0x2 & 0x4
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.
Zhao Liu [Fri, 11 Jul 2025 10:21:28 +0000 (18:21 +0800)]
i386/cpu: Add default cache model for Intel CPUs with level < 4
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
Zhao Liu [Fri, 11 Jul 2025 10:21:27 +0000 (18:21 +0800)]
i386/cpu: Add descriptor 0x49 for CPUID 0x2 encoding
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.
Xiaoyao Li [Mon, 30 Jun 2025 08:06:10 +0000 (16:06 +0800)]
i386/cpu: Unify family, model and stepping calculation for x86 CPU
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.
Roy Hopkins [Thu, 3 Jul 2025 16:21:59 +0000 (17:21 +0100)]
sev: Provide sev_features flags from IGVM VMSA to KVM_SEV_INIT2
IGVM files can contain an initial VMSA that should be applied to each
vcpu as part of the initial guest state. The sev_features flags are
provided as part of the VMSA structure. However, KVM only allows
sev_features to be set during initialization and not as the guest is
being prepared for launch.
This patch queries KVM for the supported set of sev_features flags and
processes the VP context entries in the IGVM file during kvm_init to
determine any sev_features flags set in the IGVM file. These are then
provided in the call to KVM_SEV_INIT2 to ensure the guest state
matches that specified in the IGVM file.
The igvm process() function is modified to allow a partial processing
of the file during initialization, with only the IGVM_VHT_VP_CONTEXT
fields being processed. This means the function is called twice,
firstly to extract the sev_features then secondly to actually
configure the guest.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Gerd Hoffman <kraxel@redhat.com> Tested-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Link: https://lore.kernel.org/r/b2f986aae04e1da2aee530c9be22a54c0c59a560.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Roy Hopkins [Thu, 3 Jul 2025 16:21:58 +0000 (17:21 +0100)]
i386/sev: Add implementation of CGS set_guest_policy()
The new cgs_set_guest_policy() function is provided to receive the guest
policy flags, SNP ID block and SNP ID authentication from guest
configuration such as an IGVM file and apply it to the platform prior to
launching the guest.
The policy is used to populate values for the existing 'policy',
'id_block' and 'id_auth' parameters. When provided, the guest policy is
applied and the ID block configuration is used to verify the launch
measurement and signatures. The guest is only successfully started if
the expected launch measurements match the actual measurements and the
signatures are valid.
Roy Hopkins [Thu, 3 Jul 2025 16:21:57 +0000 (17:21 +0100)]
backends/igvm: Handle policy for SEV guests
Adds a handler for the guest policy initialization IGVM section and
builds an SEV policy based on this information and the ID block
directive if present. The policy is applied using by calling
'set_guest_policy()' on the ConfidentialGuestSupport object.
Roy Hopkins [Thu, 3 Jul 2025 16:18:59 +0000 (17:18 +0100)]
backends/igvm: Process initialization sections in IGVM file
The initialization sections in IGVM files contain configuration that
should be applied to the guest platform before it is started. This
includes guest policy and other information that can affect the security
level and the startup measurement of a guest.
This commit introduces handling of the initialization sections during
processing of the IGVM file.
Roy Hopkins [Thu, 3 Jul 2025 16:02:20 +0000 (17:02 +0100)]
backends/confidential-guest-support: Add set_guest_policy() function
For confidential guests a policy can be provided that defines the
security level, debug status, expected launch measurement and other
parameters that define the configuration of the confidential platform.
This commit adds a new function named set_guest_policy() that can be
implemented by each confidential platform, such as AMD SEV to set the
policy. This will allow configuration of the policy from a
multi-platform resource such as an IGVM file without the IGVM processor
requiring specific implementation details for each platform.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffman <kraxel@redhat.com> Link: https://lore.kernel.org/r/d3888a2eb170c8d8c85a1c4b7e99accf3a15589c.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Roy Hopkins [Thu, 3 Jul 2025 16:02:19 +0000 (17:02 +0100)]
docs/interop/firmware.json: Add igvm to FirmwareDevice
Create an enum entry within FirmwareDevice for 'igvm' to describe that
an IGVM file can be used to map firmware into memory as an alternative
to pre-existing firmware devices.
Roy Hopkins [Thu, 3 Jul 2025 15:41:51 +0000 (16:41 +0100)]
docs/system: Add documentation on support for IGVM
IGVM support has been implemented for Confidential Guests that support
AMD SEV and AMD SEV-ES. Add some documentation that gives some
background on the IGVM format and how to use it to configure a
confidential guest.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffman <kraxel@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Link: https://lore.kernel.org/r/b4dc920a30717e19cd79bbbe2cc769f3b9ff3d37.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Roy Hopkins [Thu, 3 Jul 2025 15:34:41 +0000 (16:34 +0100)]
i386/sev: Implement ConfidentialGuestSupport functions for SEV
The ConfidentialGuestSupport object defines a number of virtual
functions that are called during processing of IGVM directives to query
or configure initial guest state. In order to support processing of IGVM
files, these functions need to be implemented by relevant isolation
hardware support code such as SEV.
This commit implements the required functions for SEV-ES and adds
support for processing IGVM files for configuring the guest.
Roy Hopkins [Thu, 3 Jul 2025 15:31:59 +0000 (16:31 +0100)]
i386/sev: Refactor setting of reset vector and initial CPU state
When an SEV guest is started, the reset vector and state are
extracted from metadata that is contained in the firmware volume.
In preparation for using IGVM to setup the initial CPU state,
the code has been refactored to populate vmcb_save_area for each
CPU which is then applied during guest startup and CPU reset.
Roy Hopkins [Thu, 3 Jul 2025 15:31:58 +0000 (16:31 +0100)]
target/i386: Allow setting of R_LDTR and R_TR with cpu_x86_load_seg_cache()
The x86 segment registers are identified by the X86Seg enumeration which
includes LDTR and TR as well as the normal segment registers. The
function 'cpu_x86_load_seg_cache()' uses the enum to determine which
segment to set. However, specifying R_LDTR or R_TR results in an
out-of-bounds access of the segment array.
Possibly by coincidence, the function does correctly set LDTR or TR in
this case as the structures for these registers immediately follow the
array which is accessed out of bounds.
This patch adds correct handling for R_LDTR and R_TR in the function.
Roy Hopkins [Thu, 3 Jul 2025 15:21:32 +0000 (16:21 +0100)]
sev: Update launch_update_data functions to use Error handling
The class function and implementations for updating launch data return
a code in case of error. In some cases an error message is generated and
in other cases, just the error return value is used.
This small refactor adds an 'Error **errp' parameter to all functions
which consistently set an error condition if a non-zero value is
returned.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffman <kraxel@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Link: https://lore.kernel.org/r/d59721f7b99cfc87aab71f8f551937e98e983615.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Roy Hopkins [Thu, 3 Jul 2025 15:15:34 +0000 (16:15 +0100)]
i386/pc_sysfw: Ensure sysfw flash configuration does not conflict with IGVM
When using an IGVM file the configuration of the system firmware is
defined by IGVM directives contained in the file. In this case the user
should not configure any pflash devices.
This commit skips initialization of the ROM mode when pflash0 is not set
then checks to ensure no pflash devices have been configured when using
IGVM, exiting with an error message if this is not the case.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Acked-by: Gerd Hoffman <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Link: https://lore.kernel.org/r/c6166cfe128933b04003a9288566b7affe170dfe.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Roy Hopkins [Thu, 3 Jul 2025 15:11:02 +0000 (16:11 +0100)]
hw/i386: Add igvm-cfg object and processing for IGVM files
An IGVM file contains configuration of guest state that should be
applied during configuration of the guest, before the guest is started.
This patch allows the user to add an igvm-cfg object to an X86 machine
configuration that allows an IGVM file to be configured that will be
applied to the guest before it is started.
If an IGVM configuration is provided then the IGVM file is processed at
the end of the board initialization, before the state transition to
PHASE_MACHINE_INITIALIZED.
Roy Hopkins [Thu, 3 Jul 2025 15:10:22 +0000 (16:10 +0100)]
backends/igvm: Add IGVM loader and configuration
Adds an IGVM loader to QEMU which processes a given IGVM file and
applies the directives within the file to the current guest
configuration.
The IGVM loader can be used to configure both confidential and
non-confidential guests. For confidential guests, the
ConfidentialGuestSupport object for the system is used to encrypt
memory, apply the initial CPU state and perform other confidential guest
operations.
The loader is configured via a new IgvmCfg QOM object which allows the
user to provide a path to the IGVM file to process.
Roy Hopkins [Thu, 3 Jul 2025 15:03:10 +0000 (16:03 +0100)]
backends/confidential-guest-support: Add functions to support IGVM
In preparation for supporting the processing of IGVM files to configure
guests, this adds a set of functions to ConfidentialGuestSupport
allowing configuration of secure virtual machines that can be
implemented for each supported isolation platform type such as Intel TDX
or AMD SEV-SNP. These functions will be called by IGVM processing code
in subsequent patches.
This commit provides a default implementation of the functions that
either perform no action or generate an error when they are called.
Targets that support ConfidentalGuestSupport should override these
implementations.
Roy Hopkins [Thu, 3 Jul 2025 15:00:36 +0000 (16:00 +0100)]
meson: Add optional dependency on IGVM library
The IGVM library allows Independent Guest Virtual Machine files to be
parsed and processed. IGVM files are used to configure guest memory
layout, initial processor state and other configuration pertaining to
secure virtual machines.
This adds the --enable-igvm configure option, enabled by default, which
attempts to locate and link against the IGVM library via pkgconfig and
sets CONFIG_IGVM if found.
The library is added to the system_ss target in backends/meson.build
where the IGVM parsing will be performed by the ConfidentialGuestSupport
object.
Signed-off-by: Roy Hopkins <roy.hopkins@randomman.co.uk> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffman <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Link: https://lore.kernel.org/r/45945a83a638c3f08e68c025f378e7b7f4f6d593.1751554099.git.roy.hopkins@randomman.co.uk Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
projects / thirdparty / qemu.git / log
