[Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen)

[Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen)

[Michael Tokarev]

The following patches are queued for QEMU stable v10.0.3:

  https://gitlab.com/qemu-project/qemu/-/commits/staging-10.0

Patch queue is frozen on 2025-07-21, and the release is planned for 2025-07-23:

  https://wiki.qemu.org/Planning/10.0

Please respond here or CC qemu-stable@nongnu.org on any additional patches
you think should (or shouldn't) be included in the release.

The changes which are staging for inclusion, with the original commit hash
from master branch, are given below the bottom line.

Thanks!

/mjt

--------------------------------------
01* fb8e59abbe46 Jamin Lin:
   hw/misc/aspeed_hace: Ensure HASH_IRQ is always set to prevent firmware hang
02* e6941ac10619 Jamin Lin:
   hw/arm/aspeed_ast27x0: Fix RAM size detection failure on BE hosts
03* 9498e2f7e1a2 Weifeng Liu:
   ui/gtk: Document scale and coordinate handling
04* 3a6b314409b4 Weifeng Liu:
   ui/gtk: Use consistent naming for variables in different coordinates
05* a19665448156 Weifeng Liu:
   gtk/ui: Introduce helper gd_update_scale
06* 8fb072472c38 Weifeng Liu:
   ui/gtk: Update scales in fixed-scale mode when rendering GL area
07* 30aa105640b0 Weifeng Liu:
   ui/sdl: Consider scaling in mouse event handling
08* 7ed96710e82c Daniel P. Berrangé:
   ui/vnc.c: replace big endian flag with byte order value
09* 70097442853c Daniel P. Berrangé:
   ui/vnc: take account of client byte order in pixman format
10* 63d320909220 Daniel P. Berrangé:
   ui/vnc: fix tight palette pixel encoding for 8/16-bpp formats
11* e6bc01777e5a Guenter Roeck:
   hw/arm: Add missing psci_conduit to NPCM8XX SoC boot info
12* a9403bfcd930 Huaitong Han:
   vhost: Don't set vring call if guest notifier is unused
13* 0b006153b7ec Bernhard Beschow:
   hw/i386/pc_piix: Fix RTC ISA IRQ wiring of isapc machine
14* 31753d5a336f Sairaj Kodilkar:
   hw/i386/amd_iommu: Fix device setup failure when PT is on.
15* 0f178860df34 Vasant Hegde:
   hw/i386/amd_iommu: Fix xtsup when vcpus < 255
16* 5ddd6c8dc849 Volker Rümelin:
   audio: fix SIGSEGV in AUD_get_buffer_size_out()
17* ccb4fec0e5f2 Volker Rümelin:
   audio: fix size calculation in AUD_get_buffer_size_out()
18* d009f26a54f5 Volker Rümelin:
   hw/audio/asc: fix SIGSEGV in asc_realize()
19* 0b901459a87a Xin Li (Intel):
   target/i386: Remove FRED dependency on WRMSRNS
20* 2e887187454e Stefan Hajnoczi:
   iotests: fix 240
21* eef2dd03f948 Fiona Ebner:
   hw/core/qdev-properties-system: Add missing return in set_drive_helper()
22* 9c55c03c05c1 Bibo Mao:
   hw/loongarch/virt: Fix big endian support with MCFG table
23* f5ec751ee70d Shameer Kolothum:
   hw/arm/virt: Check bypass iommu is not set for iommu-map DT property
24* e372214e663a Ethan Chen:
   qemu-options.hx: Fix reversed description of icount sleep behavior
25* cd38e638c43e Peter Maydell:
   hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions
26* 5ad2b1f443a9 J. Neuschäfer:
   linux-user/arm: Fix return value of SYS_cacheflush
27* e7788da9860c Song Gao:
   target/loongarch: add check for fcond
28* c2a2e1ad2a74 Song Gao:
   target/loongarch: fix vldi/xvldi raise wrong error
29* 0d0fc3f46589 Richard Henderson:
   tcg: Fix constant propagation in tcg_reg_alloc_dup
30* 9a3bf0e0ab62 Solomon Tan:
   target/arm: Make RETA[AB] UNDEF when pauth is not implemented
31* a412575837b6 Philippe Mathieu-Daudé:
   target/arm: Correct KVM & HVF dtb_compatible value
32* 1fa2ffdbec55 Yiwei Zhang:
   virtio-gpu: support context init multiple timeline
33* 78e378154120 Kevin Wolf:
   hw/s390x/ccw-device: Fix memory leak in loadparm setter
34* f9b0f6930407 Richard Henderson:
   target/arm: Fix SME vs AdvSIMD exception priority
35* b4b2e070f41d Richard Henderson:
   target/arm: Fix sve_access_check for SME
36* e6ffd009c771 Richard Henderson:
   target/arm: Fix 128-bit element ZIP, UZP, TRN
37* 3801c5b75ffc Richard Henderson:
   target/arm: Fix PSEL size operands to tcg_gen_gvec_ands
38* cfc688c00ade Richard Henderson:
   target/arm: Fix f16_dotadd vs nan selection
39* bf020eaa6741 Richard Henderson:
   target/arm: Fix bfdotadd_ebf vs nan selection
40* 0f1d6606c28d Mark Cave-Ayland:
   target/i386: fix TB exit logic in gen_movl_seg() when writing to SS
41* c563cd7e61d0 Peter Maydell:
   target/arm: Don't enforce NSE,NS check for EL3->EL3 returns
42* 930180f3b9a2 Bernhard Beschow:
   hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ
43* 6a3e132a1be8 Peter Maydell:
   linux-user: Implement fchmodat2 syscall
44* c4828cb8502d Peter Maydell:
   linux-user: Check for EFAULT failure in nanosleep
45* e4e839b2eeea Geoffrey Thomas:
   linux-user: Hold the fd-trans lock across fork
46* 983899eab493 Chaney, Ben:
   migration: Don't sync volatile memory after migration completes
47* d6390204c61e Peter Maydell:
   linux-user: Use qemu_set_cloexec() to mark pidfd as FD_CLOEXEC
48* f180e367fce4 Thomas Huth:
   accel/kvm: Adjust the note about the minimum required kernel version
49* 110d0fa2d4d1 Anastasia Belova:
   net: fix buffer overflow in af_xdp_umem_create()
50* adda0ad56bd2 Akihiko Odaki:
   virtio-net: Add queues for RSS during migration
51* 091c7d7924f3 Alejandro Jimenez:
   amd_iommu: Fix Miscellaneous Information Register 0 encoding
52* c63b8d1425ba Alejandro Jimenez:
   amd_iommu: Fix Device ID decoding for INVALIDATE_IOTLB_PAGES command
53* ff3dcb3bf652 Alejandro Jimenez:
   amd_iommu: Update bitmasks representing DTE reserved fields
54* 108e10ff6909 Alejandro Jimenez:
   amd_iommu: Fix masks for various IOMMU MMIO Registers
55* 123cf4bdd378 Alejandro Jimenez:
   amd_iommu: Fix mask to retrieve Interrupt Table Root Pointer from DTE
56* 67d3077ee403 Alejandro Jimenez:
   amd_iommu: Fix the calculation for Device Table size
57* 5959b641c98b Alejandro Jimenez:
   amd_iommu: Remove duplicated definitions
58* 5788929e05e1 Ethan Milon:
   amd_iommu: Fix truncation of oldval in amdvi_writeq
59* d402da1360c2 Kevin Wolf:
   file-posix: Fix aio=threads performance regression after enablign FUA
60* a598090ebaeb Cole Robinson:
   roms: re-remove execute bit from hppa-firmware*
61* 9f749129e262 David Hildenbrand:
   vhost: Fix used memslot tracking when destroying a vhost device
62* aef22331b5a4 Akihiko Odaki:
   ui/vnc: Do not copy z_stream
63* a62fef582995 Michael Tokarev:
   i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
64* 3e86124e7cb9 Qian Wen:
   i386/cpu: Fix overflow of cache topology fields in CPUID.04H
65* 5d21ee453ad8 Zhao Liu:
   i386/cpu: Honor maximum value for CPUID.8000001DH.EAX[25:14]
66 d3a24134e37d Paolo Bonzini:
   target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
67 871a6e5b339f Peter Maydell:
   hw/net/npcm_gmac.c: Send the right data for second packet in a row
68 3ac6daa9e1c5 Daniel P. Berrangé:
   ui: fix setting client_endian field defaults
69 655659a74a36 Peter Maydell:
   target/arm: Correct encoding of Debug Communications Channel registers
70 e6da704b711d Zenghui Yu:
   hvf: arm: Emulate ICC_RPR_EL1 accesses properly

(commit(s) marked with * were in previous series and are not resent)

[Stable-10.0.3 66/70] target/i386: do not expose ARCH_CAPABILITIES on AMD CPU

[Michael Tokarev]

From: Paolo Bonzini <pbonzini@redhat.com>

KVM emulates the ARCH_CAPABILITIES on x86 for both Intel and AMD
cpus, although the IA32_ARCH_CAPABILITIES MSR is an Intel-specific
MSR and it makes no sense to emulate it on AMD.

As a consequence, VMs created on AMD with qemu -cpu host and using
KVM will advertise the ARCH_CAPABILITIES feature and provide the
IA32_ARCH_CAPABILITIES MSR. This can cause issues (like Windows BSOD)
as the guest OS might not expect this MSR to exist on such cpus (the
AMD documentation specifies that ARCH_CAPABILITIES feature and MSR
are not defined on the AMD architecture).

A fix was proposed in KVM code, however KVM maintainers don't want to
change this behavior that exists for 6+ years and suggest changes to be
done in QEMU instead.  Therefore, hide the bit from "-cpu host":
migration of -cpu host guests is only possible between identical host
kernel and QEMU versions, therefore this is not a problematic breakage.

If a future AMD machine does include the MSR, that would re-expose the
Windows guest bug; but it would not be KVM/QEMU's problem at that
point, as we'd be following a genuine physical CPU impl.

Reported-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d3a24134e37d57abd3e7445842cda2717f49e96d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 6c749d4ee8..141694f803 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -500,8 +500,12 @@ uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
          * Linux v4.17-v4.20 incorrectly return ARCH_CAPABILITIES on SVM hosts.
          * We can detect the bug by checking if MSR_IA32_ARCH_CAPABILITIES is
          * returned by KVM_GET_MSR_INDEX_LIST.
+         *
+         * But also, because Windows does not like ARCH_CAPABILITIES on AMD
+         * mcahines at all, do not show the fake ARCH_CAPABILITIES MSR that
+         * KVM sets up.
          */
-        if (!has_msr_arch_capabs) {
+        if (!has_msr_arch_capabs || !(edx & CPUID_7_0_EDX_ARCH_CAPABILITIES)) {
             ret &= ~CPUID_7_0_EDX_ARCH_CAPABILITIES;
         }
     } else if (function == 7 && index == 1 && reg == R_EAX) {
-- 
2.47.2

[Stable-10.0.3 67/70] hw/net/npcm_gmac.c: Send the right data for second packet in a row

[Michael Tokarev]

From: Peter Maydell <peter.maydell@linaro.org>

The transmit loop in gmac_try_send_next_packet() is constructed in a
way that means it will send incorrect data if it it sends more than
one packet.

The function assembles the outbound data in a dynamically allocated
block of memory which is pointed to by tx_send_buffer.  We track the
first point in this block of memory which is not yet used with the
prev_buf_size offset, initially zero.  We track the size of the
packet we're sending with the length variable, also initially zero.

As we read chunks of data out of guest memory, we write them to
tx_send_buffer[prev_buf_size], and then increment both prev_buf_size
and length.  (We might dynamically reallocate the buffer if needed.)

When we send a packet, we checksum and send length bytes, starting at
tx_send_buffer, and then we reset length to 0.  This gives the right
data for the first packet.  But we don't reset prev_buf_size.  This
means that if we process more descriptors with further data for the
next packet, that data will continue to accumulate at offset
prev_buf_size, i.e.  after the data for the first packet.  But when
we transmit that second packet, we send length bytes from
tx_send_buffer, so we will send a packet which has the length of the
second packet but the data of the first one.

The fix for this is to also clear prev_buf_size after the packet has
been sent -- we never need the data from packet one after we've sent
it, so we can write packet two's data starting at the beginning of
the buffer.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 871a6e5b339f0b5e71925ec7d3f452944a1c82d3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c
index e1fb383772..d4dba630ac 100644
--- a/hw/net/npcm_gmac.c
+++ b/hw/net/npcm_gmac.c
@@ -615,6 +615,7 @@ static void gmac_try_send_next_packet(NPCMGMACState *gmac)
             trace_npcm_gmac_packet_sent(DEVICE(gmac)->canonical_path, length);
             buf = tx_send_buffer;
             length = 0;
+            prev_buf_size = 0;
         }
 
         /* step 6 */
-- 
2.47.2

[Stable-10.0.3 68/70] ui: fix setting client_endian field defaults

[Michael Tokarev]

From: Daniel P. Berrangé <berrange@redhat.com>

When a VNC client sends a "set pixel format" message, the
'client_endian' field will get initialized, however, it is
valid to omit this message if the client wants to use the
server's native pixel format. In the latter scenario nothing
is initializing the 'client_endian' field, so it remains set
to 0, matching neither G_LITTLE_ENDIAN nor G_BIG_ENDIAN. This
then results in pixel format conversion routines taking the
wrong code paths.

This problem existed before the 'client_be' flag was changed
into the 'client_endian' value, but the lack of initialization
meant it semantically defaulted to little endian, so only big
endian systems would potentially be exposed to incorrect pixel
translation.

The 'virt-viewer' / 'remote-viewer' apps always send a "set
pixel format" message so aren't exposed to any problems, but
the classical 'vncviewer' app will show the problem easily.

Fixes: 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd
Reported-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 3ac6daa9e1c5d7dae2a3cd1c6a388174b462f3e8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/ui/vnc.c b/ui/vnc.c
index ca02ff872a..a6bf8442d5 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2336,6 +2336,7 @@ static void pixel_format_message (VncState *vs) {
     char pad[3] = { 0, 0, 0 };
 
     vs->client_pf = qemu_default_pixelformat(32);
+    vs->client_endian = G_BYTE_ORDER;
 
     vnc_write_u8(vs, vs->client_pf.bits_per_pixel); /* bits-per-pixel */
     vnc_write_u8(vs, vs->client_pf.depth); /* depth */
-- 
2.47.2

[Stable-10.0.3 69/70] target/arm: Correct encoding of Debug Communications Channel registers

[Michael Tokarev]

From: Peter Maydell <peter.maydell@linaro.org>

We don't implement the Debug Communications Channel (DCC), but
we do attempt to provide dummy versions of its system registers
so that software that tries to access them doesn't fall over.

However, we got the tx/rx register definitions wrong. These
should be:

AArch32:
  DBGDTRTX   p14 0 c0 c5 0  (on writes)
  DBGDTRRX   p14 0 c0 c5 0  (on reads)

AArch64:
  DBGDTRTX_EL0  2 3 0 5 0 (on writes)
  DBGDTRRX_EL0  2 3 0 5 0 (on reads)
  DBGDTR_EL0    2 3 0 4 0 (reads and writes)

where DBGDTRTX and DBGDTRRX are effectively different names for the
same 32-bit register, which has tx behaviour on writes and rx
behaviour on reads.  The AArch64-only DBGDTR_EL0 is a 64-bit wide
register whose top and bottom halves map to the DBGDTRRX and DBGDTRTX
registers.

Currently we have just one cpreg struct, which:
 * calls itself DBGDTR_EL0
 * uses the DBGDTRTX_EL0/DBGDTRRX_EL0 encoding
 * is marked as ARM_CP_STATE_BOTH but has the wrong opc1
   value for AArch32
 * is implemented as RAZ/WI

Correct the encoding so:
 * we name the DBGDTRTX/DBGDTRRX register correctly
 * we split it into AA64 and AA32 versions so we can get the
   AA32 encoding right
 * we implement DBGDTR_EL0 at its correct encoding

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2986
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250708141049.778361-1-peter.maydell@linaro.org
(cherry picked from commit 655659a74a36b63e33d2dc969d3c44beb1b008b3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index a9a619ba6b..79c0e8eaff 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -986,11 +986,20 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
       .opc0 = 2, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 2,
       .access = PL1_RW, .accessfn = access_tdcc,
       .type = ARM_CP_CONST, .resetvalue = 0 },
-    /* DBGDTRTX_EL0/DBGDTRRX_EL0 depend on direction */
-    { .name = "DBGDTR_EL0", .state = ARM_CP_STATE_BOTH, .cp = 14,
+    /* Architecturally DBGDTRTX is named DBGDTRRX when used for reads */
+    { .name = "DBGDTRTX_EL0", .state = ARM_CP_STATE_AA64,
       .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 5, .opc2 = 0,
       .access = PL0_RW, .accessfn = access_tdcc,
       .type = ARM_CP_CONST, .resetvalue = 0 },
+    { .name = "DBGDTRTX", .state = ARM_CP_STATE_AA32, .cp = 14,
+      .opc1 = 0, .crn = 0, .crm = 5, .opc2 = 0,
+      .access = PL0_RW, .accessfn = access_tdcc,
+      .type = ARM_CP_CONST, .resetvalue = 0 },
+    /* This is AArch64-only and is a combination of DBGDTRTX and DBGDTRRX */
+    { .name = "DBGDTR_EL0", .state = ARM_CP_STATE_AA64,
+      .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 4, .opc2 = 0,
+      .access = PL0_RW, .accessfn = access_tdcc,
+      .type = ARM_CP_CONST, .resetvalue = 0 },
     /*
      * OSECCR_EL1 provides a mechanism for an operating system
      * to access the contents of EDECCR. EDECCR is not implemented though,
-- 
2.47.2

[Stable-10.0.3 70/70] hvf: arm: Emulate ICC_RPR_EL1 accesses properly

[Michael Tokarev]

From: Zenghui Yu <zenghui.yu@linux.dev>

Commit a2260983c655 ("hvf: arm: Add support for GICv3") added GICv3 support
by implementing emulation for a few system registers. ICC_RPR_EL1 was
defined but not plugged in the sysreg handlers (for no good reason).

Fix it.

Fixes: a2260983c655 ("hvf: arm: Add support for GICv3")
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250714160139.10404-3-zenghui.yu@linux.dev
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e6da704b711d5d731e4d933ad56cbbc25ee0a825)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 01e26a9726..8a4a41d15b 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -1352,6 +1352,7 @@ static int hvf_sysreg_read(CPUState *cpu, uint32_t reg, uint64_t *val)
     case SYSREG_ICC_IGRPEN0_EL1:
     case SYSREG_ICC_IGRPEN1_EL1:
     case SYSREG_ICC_PMR_EL1:
+    case SYSREG_ICC_RPR_EL1:
     case SYSREG_ICC_SGI0R_EL1:
     case SYSREG_ICC_SGI1R_EL1:
     case SYSREG_ICC_SRE_EL1:
@@ -1666,6 +1667,7 @@ static int hvf_sysreg_write(CPUState *cpu, uint32_t reg, uint64_t val)
     case SYSREG_ICC_IGRPEN0_EL1:
     case SYSREG_ICC_IGRPEN1_EL1:
     case SYSREG_ICC_PMR_EL1:
+    case SYSREG_ICC_RPR_EL1:
     case SYSREG_ICC_SGI0R_EL1:
     case SYSREG_ICC_SGI1R_EL1:
     case SYSREG_ICC_SRE_EL1:
-- 
2.47.2