Various patches related to single binary effort:
- Endianness cleanups on various targets (PPC in particular)
- Few cleanups around target_ulong type on Alpha
- Have CPUClass::disas_set_info() take a const CPUState
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmmCDTkACgkQ4+MsLN6t
# wN7vHQ/+LCAYESbTy7cXeKGgAslwPbX1Q2zYGk0rhGMgrbBtQThbgQSkNsAwYmzg
# 6vx5crw9vYA/kLq0jyJQPTRIAKzXH9BzdEfTsEt5AIpZv6Cc4im6JBZdrxUa6S0O
# AMGb4pn9bpkcwHOv2ufotJbl0fa+id4WgQgXyLDEgwgNVvY18fVWfn5OwAon2bWo
# nb6zqRfwgdyAB+liwmlPNI+M4hZ3vDdct7whUP8t37FjTL0lNrsyG/Epr0xJB5ru
# CRsjubBkXAq8HlmwHZp8JSM/Lriitp8Z2ubD8VBqYbMYI25XUnRlBWWxTnQKkaDD
# Vgbq67UqS/k/X6vV5cfJaeS2qOdgF98V0VmrOqlNXTwMU56lzMn0ThgLqUXznRos
# IUfTUvmjfGu63aAWG2l+HBrehK5JEAGYzK6ZTiTA6abpvfHUjehslsQlAlMgcSnL
# TnMsM7mxS+XNbf6bsew0azTt2p/V81JDVrQuQgmAJS9ZOpALMFGep5YAYKvN/kLf
# cSbl+hQRsxqxQPoc6y0NrnCcfT33U1+I+IXpMIR/VyC0RgseW9HeRdJWuNyKBW/4
# VUBnQnYNhZM9hDHKp5PzU2KhoeudAlK3gws8zvtWfLCFyAvfmEYX0Gt5r23JkoxT
# IO340Jz5XRwfXMWENc6Bm8lqr7HilQi28HFNXWdy897YfNS83Ow=
# =J0gm
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 04 Feb 2026 12:59:05 AM AEST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'single-binary-20260203' of https://github.com/philmd/qemu: (30 commits)
disas: Have disas_set_info() take a const CPUState
disas: Make disassemble_info::target_info field const
disas/riscv: Make rv_decode::cfg const
target/arm: Have arm_sctlr_b() take a const @env argument
target/arm: Have is_64() take a const @env argument
target/arm: Have cpu_isar_feature() use a const ARMCPU object
target/arm: Have arm_feature() take a const @env argument
target/alpha: Expand TCGv type for 64-bit target
target/alpha: Remove target_ulong uses in get_physical_address()
target/alpha: Do not use target_ulong for page table entries / indexes
target/alpha: Do not use target_ulong for trap arguments
target/alpha: Replace target_ulong -> uint64_t in gdb_write_register()
target/alpha: Build system units in common source set
target/alpha: Avoid target-specific migration headers in machine.c
target/m68k: Inline translator_ld[uw,l,q]() calls
target/i386: Inline translator_ld[uw,l,q]() calls
target/riscv: Inline translator_ld[uw,l,q]() calls
target/riscv: Inline cpu_ld[lq]_code() calls
target/ppc: Inline cpu_ldl_code() call in ppc_ldl_code()
target/ppc: Check endianness at runtime in ppc_data_endian_env()
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The CPUClass::disas_set_info() handler is meant to initialize
the %disassemble_info structure; it shoudn't alter the CPU state.
Enforce the CPUState can not be modified by having the handler
take a const pointer.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260202222412.24923-8-philmd@linaro.org>
Use the new acpi_build_madt_standalone() function to fill the MADT
parameter field.
The IGVM parameter can be consumed by Coconut SVSM [1], instead of
relying on the fw_cfg interface, which has caused problems before due to
unexpected access [2,3]. Using IGVM parameters is the default way for
Coconut SVSM across hypervisors; switching over would allow removing
specialized code paths for QEMU in Coconut.
Coconut SVSM needs to know the SMP configuration, but does not look at
any other ACPI data, nor does it interact with the PCI bus settings.
Since the MADT is static and not linked with other ACPI tables, it can
be supplied stand-alone like this.
Generating the MADT twice (during ACPI table building and IGVM processing)
seems acceptable, since there is no infrastructure to obtain the MADT
out of the ACPI table memory area.
In any case OVMF, which runs after SVSM has already been initialized,
will continue reading all ACPI tables via fw_cfg and provide fixed up
ACPI data to the OS as before without any changes.
The IGVM parameter handler is implemented for the i386 machine target
and stubbed for all others.
[1] https://github.com/coconut-svsm/svsm/pull/858
[2] https://gitlab.com/qemu-project/qemu/-/issues/2882
[3] https://github.com/coconut-svsm/svsm/issues/646
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-10-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Pass the full MachineState to the IGVM backend during file processing,
instead of just the ConfidentialGuestSupport struct (which is a member
of the MachineState).
This replaces the cgs parameter of qigvm_process_file() with the machine
state to make it available in the IGVM processing context.
We will use it later to generate MADT data there to pass to the guest
as IGVM parameter.
Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-8-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Some declarations do not depend on target-specific types,
move them out of "monitor/hmp-target.h" to "monitor/hmp.h".
Commit 409e9f7131 ("mos6522: add "info via" HMP command
for debugging") declared hmp_info_via() is declared twice.
Remove the one in "hw/misc/mos6522.h" otherwise we get:
In file included from ../hw/misc/mos6522.c:33:
include/monitor/hmp.h:43:6: error: redundant redeclaration of 'hmp_info_via' [-Werror=redundant-decls]
43 | void hmp_info_via(Monitor *mon, const QDict *qdict);
| ^~~~~~~~~~~~
In file included from ../hw/misc/mos6522.c:29:
include/hw/misc/mos6522.h:175:6: note: previous declaration of 'hmp_info_via' with type 'void(Monitor *, const QDict *)'
175 | void hmp_info_via(Monitor *mon, const QDict *qdict);
| ^~~~~~~~~~~~
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20260129164039.58472-3-philmd@linaro.org>
"target/i386/sev.h" uses the vmcb_seg structure type, which
is defined in "target/i386/svm.h". Current builds succeed
because the files including "target/i386/sev.h" also include
"monitor/hmp-target.h", itself including "cpu.h" and finally
"target/i386/svm.h".
Include the latter, otherwise removing "cpu.h" from
"monitor/hmp-target.h" triggers:
../target/i386/sev.h:62:21: error: field has incomplete type 'struct vmcb_seg'
62 | struct vmcb_seg es;
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20260129164039.58472-2-philmd@linaro.org>
32-bit TCG opcodes produced for the i386 target usually looks the same
as 64-bit TCG opcodes produced for the x86_64. The special one that
needs extensions is 32-bit TCG opcodes produced for the x86_64 target.
Make all #ifdefs look the same, like this:
case MO_32:
#ifdef TARGET_X86_64
/* code using 32-bit opcodes */
case MO_64:
#endif
/* code using target_long opcodes */
default:
g_assert_not_reached();
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Unlike the older code in translate.c, mod=11b *is* filtered out earlier
by decode_modrm, and it would have returned bogus code. Since the register
case is so simple, just inline decode_modrm_address into its caller instead
of removing the "if".
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
NB_OP_SIZES has been dead since the conversion to TCG, REG_L_OFFSET
since 2015, the others somewhere in the middle.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Match the contents of table 2-17 ("#UD Exception and VEX.L Field Encoding")
in the SDM, for instruction in exception class 5. They were incorrectly
accepting 256-bit versions that do not exist.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
target-arm queue:
* hw/arm/imx8mp-evk: Provide some defaults matching real hardware
* hw/intc: endianness fixes
* various: Clean up includes
* kernel-doc.py: sync with upstream Kernel v6.19-rc4
* scripts/clean-includes: Minor improvements; exclude list update
* docs/system/arm/imx8mp-evk: Avoid suggesting redundant CLI parameters
* docs/system/arm/xlnx-zynq.rst: Improve docs rendering
* docs: Be consistent about capitalization of 'Arm' (again)
* docs: Avoid unintended mailto: hyperlinks
* qemu-options.hx: Drop uses of @var
* qemu-options.hx: Improve formatting in colo-compare docs
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmlzju4ZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3uU/D/9IHpo57UIHAF7vU9gsWm5k
# TxLl9PBw3ev2Uv6zWWza0wYZQF2ZcvqwMiU/AlBFuyJFyXTLocL3iN6Rsw+8kcjh
# jaq2hCtzSNJWj41CEU22l7iUfJ5PdOVdRYhhwlrQqxXDJj8Oj3plliRc6AL1EZYD
# mxAJ+YQ8pfJ/2ibO66sqwGMLjPsjCmmgfloTm/qFzk7QccQkPZKzDrC9CGGRmmRA
# tcdBGMtu+DOqpCRKIRul0S8ed2qaTecIK3+fUID0+qEzb10VWgFs/AAQiwLPkwyi
# RvMmIbC9lYVCnP+YC4HlvYMfd61V3lpzsUXgMIbdRZYsN/IlTVfetJUOVmn3LTQ/
# gGU0b+t6D/OZAt1L6toBngKVh89VPqbpGXEx4UMHCNIcvfI1Xo+HRT9ZV5WCw6b8
# sVKOZUwKs9ZbFAcrgBgskXp/5KWZAb92IFjwbfwxxl/2NRK3B3y7CDHBoOM/zQ9a
# rZ7rfJHhQVGR2+1QonNbpG0IFwbgs0zPQwBjPreGh6TWf2UiXvx1ku94Wxe2lA+5
# CPeju+swbFKRNjwSas6NZjJWazacohYG3nhmhF7HtcgX279BzIV0d+ZIl786Juls
# 4Vt4dPUxU/kHHZHjE52AZUS/opIy+UHAj0FKPAPpTrc7UfuHlY3gqoI7UfVpciau
# q3DqM7PlF2X91kw4xJ6JCA==
# =bE6w
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 24 Jan 2026 02:08:30 AM AEDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [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: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260123' of https://gitlab.com/pm215/qemu: (22 commits)
qemu-options.hx: Improve formatting in colo-compare docs
qemu-options.hx: Drop uses of @var
docs: avoid unintended mailto: hyperlinks
docs/system/arm/xlnx-zynq.rst: Improve docs rendering
hw/intc: avoid byte swap fiddling in gicv3 its path
hw/intc: declare GICv3 regions as little endian
hw/intc: declare GIC regions as little endian
hw/intc: declare NVIC regions as little endian
all: Clean up includes
misc: Clean up includes
bsd-user: Clean up includes
mshv: Clean up includes
scripts/clean-includes: Update exclude list
scripts/clean-includes: Give the args in git commit messages
scripts/clean-includes: Do all our exclusions with REGEXFILE
scripts/clean-includes: Make ignore-regexes one per line
scripts/clean-includes: Remove outdated comment
scripts/clean-includes: Allow directories on command line
docs: Be consistent about capitalization of 'Arm' (again)
kernel-doc.py: sync with upstream Kernel v6.19-rc4
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit was created with scripts/clean-includes:
./scripts/clean-includes '--git' 'all' '--all'
and manually edited to remove one change to hw/virtio/cbor-helpers.c.
All these changes are header files that include osdep.h or some
system header that osdep.h pulls in; they don't need to do this.
All .c should include qemu/osdep.h first. The script performs three
related cleanups:
* Ensure .c files include qemu/osdep.h first.
* Including it in a .h is redundant, since the .c already includes
it. Drop such inclusions.
* Likewise, including headers qemu/osdep.h includes is redundant.
Drop these, too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260116125830.926296-5-peter.maydell@linaro.org
This commit deals with various .c files that included system
headers that are already pulled in by osdep.h, where the .c
file includes osdep.h already itself.
This commit was created with scripts/clean-includes:
./scripts/clean-includes '--git' 'misc' 'hw/core' 'semihosting' 'target/arm' 'target/i386/kvm/kvm.c' 'target/loongarch' 'target/riscv' 'tools' 'util'
All .c should include qemu/osdep.h first. The script performs three
related cleanups:
* Ensure .c files include qemu/osdep.h first.
* Including it in a .h is redundant, since the .c already includes
it. Drop such inclusions.
* Likewise, including headers qemu/osdep.h includes is redundant.
Drop these, too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260116125830.926296-4-peter.maydell@linaro.org
This commit was created with scripts/clean-includes:
./scripts/clean-includes '--git' 'mshv' 'accel/mshv' 'target/i386/mshv' 'include/system/mshv.h'
All .c should include qemu/osdep.h first. The script performs three
related cleanups:
* Ensure .c files include qemu/osdep.h first.
* Including it in a .h is redundant, since the .c already includes
it. Drop such inclusions.
* Likewise, including headers qemu/osdep.h includes is redundant.
Drop these, too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260116125830.926296-2-peter.maydell@linaro.org
We only build the X86 targets using little endianness order,
therefore the cpu_ld/st_data*() definitions expand to the little
endian declarations. Use the explicit little-endian variants.
Mechanical change running:
$ tgt=i386; \
end=le; \
for op in data mmuidx_ra; do \
for ac in uw sw l q; do \
sed -i -e "s/cpu_ld${ac}_${op}/cpu_ld${ac}_${end}_${op}/" \
$(git grep -l cpu_ target/${tgt}/); \
done;
for ac in w l q; do \
sed -i -e "s/cpu_st${ac}_${op}/cpu_st${ac}_${end}_${op}/" \
$(git grep -l cpu_ target/${tgt}/); \
done;
done
Then adapting indentation in helper_vmload() to pass checkpatch.pl.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251126202200.23100-3-philmd@linaro.org>
Remove instances of __i386__, except from tests and imported headers.
Drop a block containing sanity check and fprintf error message for
i386-on-i386 or x86_64-on-x86_64 emulation. If we really want
something like this, we would do it via some form of compile-time check.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Compiling on NetBSD currently fails with:
../src/target/i386/nvmm/nvmm-all.c:1136:22: error: unknown type name 'RAMBlockNotifier'
1136 | nvmm_ram_block_added(RAMBlockNotifier *n, void *host, size_t size,
| ^~~~~~~~~~~~~~~~
../src/target/i386/nvmm/nvmm-all.c:1152:15: error: variable 'nvmm_ram_notifier' has initializer but incomplete type
1152 | static struct RAMBlockNotifier nvmm_ram_notifier = {
| ^~~~~~~~~~~~~~~~
../src/target/i386/nvmm/nvmm-all.c:1153:6: error: 'struct RAMBlockNotifier' has no member named 'ram_block_added'
1153 | .ram_block_added = nvmm_ram_block_added
| ^~~~~~~~~~~~~~~
../src/target/i386/nvmm/nvmm-all.c:1153:24: error: 'nvmm_ram_block_added' undeclared here (not in a function)
1153 | .ram_block_added = nvmm_ram_block_added
| ^~~~~~~~~~~~~~~~~~~~
Include the right header to get this fixed.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20260114083812.18496-1-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The hvf_slot structure is a poor replacement for properly
looking up a memory region in the address space.
Use memory_region_get_dirty_log_mask instead of HVF_SLOT_LOG.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20251103101034.59039-6-philmd@linaro.org>
If the vex_special field was not initialized, it was considered to be
X86_VEX_SSEUnaligned (whose value was zero). Add a new value to
fix that.
Cc: qemu-stable@nongnu.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove dead code; it arose when I noticed that, because 0x3? opcodes do
have a pop, case 0x32 works just fine as fcomp (even though 0x?2 is fcom):
there is no need to hack the op to 0x03.
Reported by Coverity as CID 1643922.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The value that is pushed by PUSHF is the full EFLAGS, while CC_OP_EFLAGS
only wants arithmetic flags in CC_SRC. To avoid this, follow what other
helpers do and set CC_SRC/CC_OP directly in helper_read_eflags. This
is basically free and fixes an issue booting Windows 3.11.
Reported-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Fixes: e661e2d7a3 ("target/i386/tcg: update cc_op after PUSHF", 2025-12-27)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Replace
error_setg_errno(errp, errno, MSG, FNAME);
by
error_setg_file_open(errp, errno, FNAME);
where MSG is "Could not open '%s'" or similar.
Also replace equivalent uses of error_setg().
A few messages lose prefixes ("net dump: ", "SEV: ", __func__ ": ").
We could put them back with error_prepend(). Not worth the bother.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Message-ID: <20251121121438.1249498-11-armbru@redhat.com>
[Conflict with commit 26b4a6ffe7 (monitor/hmp: Merge
hmp-cmds-target.c within hmp-cmds.c) resolved]
According to table 1-2 in Intel Architecture Instruction Set Extensions
and Future Features (rev 059), Diamond Rapids has the following new
features which have already been supported for guest:
* SM4 (EVEX)
* Intel Advanced Vector Extensions 10 Version 2 (Intel AVX10.2)
* MOVRS and the PREFETCHRST2 instruction
* AMX-MOVRS, AMX-AVX512, AMX-FP8, AMX-TF32
* Intel Advanced Performance Extensions
And FRED - Flexible Return and Event Delivery (FRED) and the LKGS
instruction (introduced since Clearwater Forest & Diamond Rapids) - is
included in Diamond Rapids CPU model.
In addition, the following features are added into Diamond Rapids CPU
model:
* CET: Control-flow Enforcement Technology (introduced since Sapphire
Rapids & Sierra Forest).
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-11-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Many Intel CPUs enable CPUID 0x1f by default to encode CPU topology
information.
Add the "cpuid_0x1f" option to X86CPUDefinition to allow named CPU
models to configure CPUID 0x1f from the start, thereby forcing 0x1f
to be present for guest.
With this option, there's no need to explicitly add v1 model to an
unversioned CPU model for explicitly enabling the x-force-cpuid-0x1f
property.
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-9-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In CPUID 0x4 leaf, it's possible to make the cache privated at thread
level when there's no HT within the core. In this case, while cache per
thread and cache per core are essentially identical, their topology
information differs in CPUID 0x4.
Diamond Rapids assigns the L1 i/d cache at the thread level. To allow
accurate emulation of DMR cache topology, remove the cache-per-thread
restriction in max_thread_ids_for_cache(), which enables CPUID 0x4 to
support cache per thread topology.
Given that after adding thread-level support, the topology offset
information required by max_thread_ids_for_cache() can be sufficiently
provided by apicid_offset_by_topo_level(), so it's straightforward to
re-implement max_thread_ids_for_cache() based on
apicid_offset_by_topo_level() to reduce redundant duplicate codes.
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-8-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Intel AVX10 Version 2 (Intel AVX10.2) includes a suite of new
instructions delivering new AI features and performance, accelerated
media processing, expanded Web Assembly, and Cryptography support, along
with enhancements to existing legacy instructions for completeness and
efficiency, and it is enumerated as version 2 in CPUID 0x24.0x0.EBX[bits
0-7] [*].
Considerring "Intel CPUs which support Intel AVX10.2 will include an
enumeration for AVX10_VNNI_INT (CPUID.24H.01H:ECX.AVX10_VNNI_INT[2])"
[*] and EVEX VPDP* instructions for INT8/INT16 (AVX10_VNNI_INT) are
detected by either AVX10.2 OR AVX10_VNNI_INT, AVX10_VNNI_INT is part of
AVX10.2, so any Intel AVX10.2 implementation lacking the AVX10_VNNI_INT
enumeration should be considered buggy hardware.
Therefore, it's necessary to set AVX10_VNNI_INT enumeration for Guest
when the user specifies AVX10 version 2. For this, introduce AVX10
models to explicitly define the feature bits included in different AVX10
versions.
[*]: Intel Advanced Vector Extensions 10.2 Architecture Specification
(rev 5.0).
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-5-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
AVX10_VNNI_INT (0x24.0x1.ECX[bit 2]) is a discrete feature bit
introduced on Intel Diamond Rapids, which enumerates the support for
EVEX VPDP* instructions for INT8/INT16 [*].
Although Intel AVX10.2 has already included new VPDP* INT8/INT16 VNNI
instructions, a bit - AVX10_VNNI_INT - is still be separated. Relevant
new instructions can be checked by either CPUID AVX10.2 OR
AVX10_VNNI_INT (e.g., VPDPBSSD).
Support CPUID 0x24.0x1 subleaf with AVX10_VNNI_INT enumeration for
Guest.
[*]: Intel Advanced Vector Extensions 10.2 Architecture Specification
(rev 5.0).
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-4-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Intel Diamond Rapids adds new AMX instructions to support new formats
and memory operations [*]. And it introduces the CPUID subleaf 0x1E.0x1
to centralize the discrete AMX feature bits within EAX.
For new feature bits (CPUID 0x1E.0x1.EAX[bits 4,6-8]), it's
straightforward to add their enurmeration support.
In addition to the new features, CPUID 0x1E.0x1.EAX[bits 0-3] are
mirrored positions of existing AMX feature bits distributing across
the 0x7 leaves. It's not flexible to make these mirror bits have the
same names as existing ones, because QEMU would try to set both original
bit and mirror bit which would cause warning if host doesn't support
0x1E.0x1 subleaf. Thus, name these mirror bits with "*-mirror" suffix.
[*]: Intel Architecture Instruction Set Extensions and Future Features
(rev.059).
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-3-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
MOVRS is a new set of instructions introduced in the Intel platform
Diamond Rapids, to load instructions that carry a read-shared hint.
Functionally, MOVRS family is equivalent to existing load instructions,
but its read-shared hint indicates the source memory location is likely
to become read-shared by multiple processors, i.e., read in the future
by at least one other processor before it is written (assuming it is
ever written in the future). It could optimize the behavior of the
caches, especially shared caches, for this data for future reads by
multiple processors. Additionally, MOVRS family also includes a software
prefetch instruction, PREFETCHRST2, that carries the same read-shared
hint. [*]
MOVRS family is enumerated by CPUID single-bit (0x7.0x1.EAX[bit 31]).
Add its enumeration support.
[*]: Intel Architecture Instruction Set Extensions and Future Features
(rev.059).
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/r/20251215073743.4055227-2-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
PF/ZF/SF are computed the same way for almost all CC_OP values (depending
only on the operand size in the case of ZF and SF). The only exception is
PF for CC_OP_BLSI* and CC_OP_BMILG*; but AMD documents that PF should
be computed normally (rather than being undefined) so that is a kind of
bug fix.
Put the common code at the end of helper_cc_compute_all, shaving
another kB from its text.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Let translate.c only concern itself with TCG code generation. Move everything
that uses CPUX86State*, as well as gen_lea_modrm_0 now that it is only used
to fill decode->mem, to decode-new.c.inc.
While at it also rename gen_lea_modrm_0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
