Branch: refs/heads/staging-7.2
Home: https://github.com/qemu/qemu
Commit: d3dd2ae296e4c993de074b824dd5f358820b0bba
https://github.com/qemu/qemu/commit/d3dd2ae296e4c993de074b824dd5f358820b0bba
Author: LIU Zhiwei <[email protected]>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M target/riscv/insn_trans/trans_privileged.c.inc
Log Message:
-----------
target/riscv: Fix itrigger when icount is used
When I boot a ubuntu image, QEMU output a "Bad icount read" message and exit.
The reason is that when execute helper_mret or helper_sret, it will
cause a call to icount_get_raw_locked (), which needs set can_do_io flag
on cpustate.
Thus we setting this flag when execute these two instructions.
Signed-off-by: LIU Zhiwei <[email protected]>
Reviewed-by: Weiwei Li <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Commit: 1352279fbf90d19c386aea0923801d0204d7a433
https://github.com/qemu/qemu/commit/1352279fbf90d19c386aea0923801d0204d7a433
Author: Richard Henderson <[email protected]>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M accel/tcg/cputlb.c
Log Message:
-----------
accel/tcg: Fix atomic_mmu_lookup for reads
A copy-paste bug had us looking at the victim cache for writes.
Cc: [email protected]
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Fixes: 08dff435e2 ("tcg: Probe the proper permissions for atomic ops")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 8c313254e61ed47a1bf4a2db714b25cdd94fbcce)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 143b3619bbe8710dbcd21b988df582830c442595
https://github.com/qemu/qemu/commit/143b3619bbe8710dbcd21b988df582830c442595
Author: Peter Maydell <[email protected]>
Date: 2023-05-15 (Mon, 15 May 2023)
Changed paths:
M ui/console.c
Log Message:
-----------
ui: Fix pixel colour channel order for PNG screenshots
When we take a PNG screenshot the ordering of the colour channels in
the data is not correct, resulting in the image having weird
colouring compared to the actual display. (Specifically, on a
little-endian host the blue and red channels are swapped; on
big-endian everything is wrong.)
This happens because the pixman idea of the pixel data and the libpng
idea differ. PIXMAN_a8r8g8b8 defines that pixels are 32-bit values,
with A in bits 24-31, R in bits 16-23, G in bits 8-15 and B in bits
0-7. This means that on little-endian systems the bytes in memory
are
B G R A
and on big-endian systems they are
A R G B
libpng, on the other hand, thinks of pixels as being a series of
values for each channel, so its format PNG_COLOR_TYPE_RGB_ALPHA
always wants bytes in the order
R G B A
This isn't the same as the pixman order for either big or little
endian hosts.
The alpha channel is also unnecessary bulk in the output PNG file,
because there is no alpha information in a screenshot.
To handle the endianness issue, we already define in ui/qemu-pixman.h
various PIXMAN_BE_* and PIXMAN_LE_* values that give consistent
byte-order pixel channel formats. So we can use PIXMAN_BE_r8g8b8 and
PNG_COLOR_TYPE_RGB, which both have an in-memory byte order of
R G B
and 3 bytes per pixel.
(PPM format screenshots get this right; they already use the
PIXMAN_BE_r8g8b8 format.)
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1622
Fixes: 9a0a119a382867 ("Added parameter to take screenshot with screendump as
PNG")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-id: [email protected]
(cherry picked from commit cd22a0f520f471e3bd33bc19cf3b2fa772cdb2a8)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/23547d84b6c4...143b3619bbe8
