Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: 24778b1c7ee7aca9721ed4757b0e0df0c16390f7
https://github.com/qemu/qemu/commit/24778b1c7ee7aca9721ed4757b0e0df0c16390f7
Author: Paolo Bonzini <[email protected]>
Date: 2025-07-19 (Sat, 19 Jul 2025)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
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 <[email protected]>
Suggested-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit d3a24134e37d57abd3e7445842cda2717f49e96d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9561a8c14049a851bb5b83d92707bec2d6692052
https://github.com/qemu/qemu/commit/9561a8c14049a851bb5b83d92707bec2d6692052
Author: Peter Maydell <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M hw/net/npcm_gmac.c
Log Message:
-----------
hw/net/npcm_gmac.c: Send the right data for second packet in a row
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: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 871a6e5b339f0b5e71925ec7d3f452944a1c82d3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 08fa61a3652e36e6966bc6a3473f7a333c4058a5
https://github.com/qemu/qemu/commit/08fa61a3652e36e6966bc6a3473f7a333c4058a5
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui: fix setting client_endian field defaults
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 <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 3ac6daa9e1c5d7dae2a3cd1c6a388174b462f3e8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3341f5cd5c391c6b460f2f70cc694ca5ef3b2191
https://github.com/qemu/qemu/commit/3341f5cd5c391c6b460f2f70cc694ca5ef3b2191
Author: Peter Maydell <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M target/arm/debug_helper.c
Log Message:
-----------
target/arm: Correct encoding of Debug Communications Channel registers
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: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2986
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 655659a74a36b63e33d2dc969d3c44beb1b008b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a5ac9803d513586eefe6c7613b3c3bcc1b9e5943
https://github.com/qemu/qemu/commit/a5ac9803d513586eefe6c7613b3c3bcc1b9e5943
Author: Zenghui Yu <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
hvf: arm: Emulate ICC_RPR_EL1 accesses properly
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 <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e6da704b711d5d731e4d933ad56cbbc25ee0a825)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/82517381c54d...a5ac9803d513
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
