[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] d3dd2a: target/riscv: Fix itrigger when icoun

From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] d3dd2a: target/riscv: Fix itrigger when icount is used
Date: Mon, 15 May 2023 03:57:25 -0700

  Branch: refs/heads/staging-7.2
  Home:   https://github.com/qemu/qemu
  Commit: d3dd2ae296e4c993de074b824dd5f358820b0bba
  Author: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
  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 <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230324064011.976-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

  Commit: 1352279fbf90d19c386aea0923801d0204d7a433
  Author: Richard Henderson <richard.henderson@linaro.org>
  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: qemu-stable@nongnu.org
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Fixes: 08dff435e2 ("tcg: Probe the proper permissions for atomic ops")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20230505204049.352469-1-richard.henderson@linaro.org>
(cherry picked from commit 8c313254e61ed47a1bf4a2db714b25cdd94fbcce)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 143b3619bbe8710dbcd21b988df582830c442595
  Author: Peter Maydell <peter.maydell@linaro.org>
  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
   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: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1622
Fixes: 9a0a119a382867 ("Added parameter to take screenshot with screendump as 
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20230502135548.2451309-1-peter.maydell@linaro.org
(cherry picked from commit cd22a0f520f471e3bd33bc19cf3b2fa772cdb2a8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Compare: https://github.com/qemu/qemu/compare/23547d84b6c4...143b3619bbe8

reply via email to

[Prev in Thread] Current Thread [Next in Thread]