* [Stable-10.0.3 66/70] target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
2025-07-21 20:02 [Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen) Michael Tokarev
@ 2025-07-21 20:02 ` Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 67/70] hw/net/npcm_gmac.c: Send the right data for second packet in a row Michael Tokarev
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Michael Tokarev @ 2025-07-21 20:02 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Paolo Bonzini, Alexandre Chartre,
Daniel P. Berrangé, Xiaoyao Li, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [Stable-10.0.3 67/70] hw/net/npcm_gmac.c: Send the right data for second packet in a row
2025-07-21 20:02 [Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen) Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 66/70] target/i386: do not expose ARCH_CAPABILITIES on AMD CPU Michael Tokarev
@ 2025-07-21 20:02 ` Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 68/70] ui: fix setting client_endian field defaults Michael Tokarev
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Michael Tokarev @ 2025-07-21 20:02 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Peter Maydell, Jason Wang, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [Stable-10.0.3 68/70] ui: fix setting client_endian field defaults
2025-07-21 20:02 [Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen) Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 66/70] target/i386: do not expose ARCH_CAPABILITIES on AMD CPU Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 67/70] hw/net/npcm_gmac.c: Send the right data for second packet in a row Michael Tokarev
@ 2025-07-21 20:02 ` Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 69/70] target/arm: Correct encoding of Debug Communications Channel registers Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 70/70] hvf: arm: Emulate ICC_RPR_EL1 accesses properly Michael Tokarev
4 siblings, 0 replies; 6+ messages in thread
From: Michael Tokarev @ 2025-07-21 20:02 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Daniel P. Berrangé, Thomas Huth,
Philippe Mathieu-Daudé, Marc-André Lureau,
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [Stable-10.0.3 69/70] target/arm: Correct encoding of Debug Communications Channel registers
2025-07-21 20:02 [Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen) Michael Tokarev
` (2 preceding siblings ...)
2025-07-21 20:02 ` [Stable-10.0.3 68/70] ui: fix setting client_endian field defaults Michael Tokarev
@ 2025-07-21 20:02 ` Michael Tokarev
2025-07-21 20:02 ` [Stable-10.0.3 70/70] hvf: arm: Emulate ICC_RPR_EL1 accesses properly Michael Tokarev
4 siblings, 0 replies; 6+ messages in thread
From: Michael Tokarev @ 2025-07-21 20:02 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Peter Maydell, Richard Henderson, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* [Stable-10.0.3 70/70] hvf: arm: Emulate ICC_RPR_EL1 accesses properly
2025-07-21 20:02 [Stable-10.0.3 v3 00/70] Patch Round-up for stable 10.0.3, freeze on 2025-07-21 (frozen) Michael Tokarev
` (3 preceding siblings ...)
2025-07-21 20:02 ` [Stable-10.0.3 69/70] target/arm: Correct encoding of Debug Communications Channel registers Michael Tokarev
@ 2025-07-21 20:02 ` Michael Tokarev
4 siblings, 0 replies; 6+ messages in thread
From: Michael Tokarev @ 2025-07-21 20:02 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Zenghui Yu, Philippe Mathieu-Daudé,
Peter Maydell, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread