Branch: refs/heads/staging-7.2
  Home:   https://github.com/qemu/qemu
  Commit: b6ecf105179bdb52d439c642161d895c686af921
      
https://github.com/qemu/qemu/commit/b6ecf105179bdb52d439c642161d895c686af921
  Author: Stefan Berger <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M tests/qtest/tpm-tests.c

  Log Message:
  -----------
  tests: Wait for migration completion on destination QEMU to avoid failures

Rather than waiting for the completion of migration on the source side,
wait for it on the destination QEMU side to avoid accessing the TPM TIS
memory mapped registers before QEMU could restore their state. This
error condition could be triggered on busy systems where the destination
QEMU did not have enough time to restore the TIS state while the test case
was already reading its registers. The test case was for example reading
the STS register and received an unexpected value (0xffffffff), which
lead to a segmentation fault later on due to trying to read 0xffff bytes
from the TIS into a buffer.

Cc:  <[email protected]>
Reported-by: Fabiano Rosas <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Stefan Berger <[email protected]>
(cherry picked from commit d9280ea3174700170d39c4cdd3f587f260757711)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 1284606faf6a63a715942a4d52462d72e2217569
      
https://github.com/qemu/qemu/commit/1284606faf6a63a715942a4d52462d72e2217569
  Author: Kevin Wolf <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M block/raw-format.c

  Log Message:
  -----------
  raw-format: Fix error message for invalid offset/size

s->offset and s->size are only set at the end of the function and still
contain the old values when formatting the error message. Print the
parameters with the new values that we actually checked instead.

Fixes: 500e2434207d ('raw-format: Split raw_read_options()')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 04bbc3ee52b32ac465547bb40c1f090a1b8f315a)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 16ac2273d170d13346c99db531ce1cb389f50d5a
      
https://github.com/qemu/qemu/commit/16ac2273d170d13346c99db531ce1cb389f50d5a
  Author: Richard Henderson <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M tcg/tcg.c

  Log Message:
  -----------
  tcg: Reset data_gen_ptr correctly

This pointer needs to be reset after overflow just like
code_buf and code_ptr.

Cc: [email protected]
Fixes: 57a269469db ("tcg: Infrastructure for managing constant pools")
Acked-by: Alistair Francis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: LIU Zhiwei <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit a7cfd751fb269de4a93bf1658cb13911c7ac77cc)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 6d36cf89d36f22c7da2c33ff52008932a62b4a34
      
https://github.com/qemu/qemu/commit/6d36cf89d36f22c7da2c33ff52008932a62b4a34
  Author: Peter Maydell <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/i386/tcg/sysemu/excp_helper.c

  Log Message:
  -----------
  target/i386: Avoid unreachable variable declaration in mmu_translate()

Coverity complains (CID 1507880) that the declaration "int error_code;"
in mmu_translate() is unreachable code. Since this is only a declaration,
this isn't actually a bug, but:
 * it's a bear-trap for future changes, because if it was changed to
   include an initialization 'int error_code = foo;' then the
   initialization wouldn't actually happen (being dead code)
 * it's against our coding style, which wants declarations to be
   at the start of blocks
 * it means that anybody reading the code has to go and look up
   exactly what the C rules are for skipping over variable declarations
   using a goto

Move the declaration to the top of the function.

Signed-off-by: Peter Maydell <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 987b63f24afe027a09b1c549c05a032a477f7e96)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: cherry-pick this for stable-7.2 so that the next patch applies cleanly)


  Commit: c363ebaa19c3de428982fd634f4acb89b240aa41
      
https://github.com/qemu/qemu/commit/c363ebaa19c3de428982fd634f4acb89b240aa41
  Author: Alexander Graf <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/i386/tcg/sysemu/excp_helper.c

  Log Message:
  -----------
  target/i386: Walk NPT in guest real mode

When translating virtual to physical address with a guest CPU that
supports nested paging (NPT), we need to perform every page table walk
access indirectly through the NPT, which we correctly do.

However, we treat real mode (no page table walk) special: In that case,
we currently just skip any walks and translate VA -> PA. With NPT
enabled, we also need to then perform NPT walk to do GVA -> GPA -> HPA
which we fail to do so far.

The net result of that is that TCG VMs with NPT enabled that execute
real mode code (like SeaBIOS) end up with GPA==HPA mappings which means
the guest accesses host code and data. This typically shows as failure
to boot guests.

This patch changes the page walk logic for NPT enabled guests so that we
always perform a GVA -> GPA translation and then skip any logic that
requires an actual PTE.

That way, all remaining logic to walk the NPT stays and we successfully
walk the NPT in real mode.

Cc: [email protected]
Fixes: fe441054bb3f0 ("target-i386: Add NPT support")
Signed-off-by: Alexander Graf <[email protected]>
Reported-by: Eduard Vlad <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b56617bbcb473c25815d1bf475e326f84563b1de)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 1d6dee3e8a3b74add804c41fd7934a3dbb3290fa
      
https://github.com/qemu/qemu/commit/1d6dee3e8a3b74add804c41fd7934a3dbb3290fa
  Author: Ilya Leoshkevich <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M linux-user/ppc/signal.c

  Log Message:
  -----------
  linux-user/ppc: Fix sigmask endianness issue in sigreturn

do_setcontext() copies the target sigmask without endianness handling
and then uses target_to_host_sigset_internal(), which expects a
byte-swapped one. Use target_to_host_sigset() instead.

Fixes: bcd4933a23f1 ("linux-user: ppc signal handling")
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8704132805cf7a3259d1c5a073b3c2b92afa2616)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 28acf4339d6aa6c7519ec652fba53cdecac7275d
      
https://github.com/qemu/qemu/commit/28acf4339d6aa6c7519ec652fba53cdecac7275d
  Author: Alex Bennée <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M .gitlab-ci.d/check-dco.py
    M .gitlab-ci.d/check-patch.py

  Log Message:
  -----------
  gitlab: make check-[dco|patch] a little more verbose

When git fails the rather terse backtrace only indicates it failed
without some useful context. Add some to make the log a little more
useful.

Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 97f116f9c6fd127b6ed2953993fa9fb05e82f450)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: context fix for stable-7.2)


  Commit: 50ca7f1fb461da3a0094f287ca2197ae52a2e5fc
      
https://github.com/qemu/qemu/commit/50ca7f1fb461da3a0094f287ca2197ae52a2e5fc
  Author: Stefan Weil <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M net/colo-compare.c

  Log Message:
  -----------
  Fix calculation of minimum in colo_compare_tcp

GitHub's CodeQL reports a critical error which is fixed by using the MIN macro:

    Unsigned difference expression compared to zero

Signed-off-by: Stefan Weil <[email protected]>
Cc: [email protected]
Reviewed-by: Zhang Chen <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit e29bc931e1699a98959680f6776b48673825762b)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: fccdc16414bc993e8028579a6a4eeb108b79d332
      
https://github.com/qemu/qemu/commit/fccdc16414bc993e8028579a6a4eeb108b79d332
  Author: Bernhard Beschow <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M net/tap-win32.c

  Log Message:
  -----------
  net/tap-win32: Fix gcc 14 format truncation errors

The patch fixes the following errors generated by GCC 14.2:

../src/net/tap-win32.c:343:19: error: '%s' directive output may be truncated 
writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=]
  343 |              "%s\\%s\\Connection",
      |                   ^~
  344 |              NETWORK_CONNECTIONS_KEY, enum_name);
      |                                       ~~~~~~~~~

../src/net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes 
into a destination of size 256
  341 |         snprintf(connection_string,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  342 |              sizeof(connection_string),
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~
  343 |              "%s\\%s\\Connection",
      |              ~~~~~~~~~~~~~~~~~~~~~
  344 |              NETWORK_CONNECTIONS_KEY, enum_name);
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../src/net/tap-win32.c:242:58: error: '%s' directive output may be truncated 
writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=]
  242 |         snprintf (unit_string, sizeof(unit_string), "%s\\%s",
      |                                                          ^~
  243 |                   ADAPTER_KEY, enum_name);
      |                                ~~~~~~~~~

../src/net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes 
into a destination of size 256
  242 |         snprintf (unit_string, sizeof(unit_string), "%s\\%s",
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  243 |                   ADAPTER_KEY, enum_name);
      |                   ~~~~~~~~~~~~~~~~~~~~~~~

../src/net/tap-win32.c:620:52: error: '%s' directive output may be truncated 
writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=]
  620 |     snprintf (device_path, sizeof(device_path), "%s%s%s",
      |                                                    ^~
  621 |               USERMODEDEVICEDIR,
  622 |               device_guid,
      |               ~~~~~~~~~~~
../src/net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes 
into a destination of size 256
  620 |     snprintf (device_path, sizeof(device_path), "%s%s%s",
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  621 |               USERMODEDEVICEDIR,
      |               ~~~~~~~~~~~~~~~~~~
  622 |               device_guid,
      |               ~~~~~~~~~~~~
  623 |               TAPSUFFIX);
      |               ~~~~~~~~~~

Signed-off-by: Bernhard Beschow <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2607
Cc: [email protected]
Reviewed-by: Michael Tokarev <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 75fe36b4e8a994cdf9fd6eb601f49e96b1bc791d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 004f0583f126b33b6b76f421f14637c3928165cd
      
https://github.com/qemu/qemu/commit/004f0583f126b33b6b76f421f14637c3928165cd
  Author: Peter Maydell <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/arm/internals.h

  Log Message:
  -----------
  target/arm: Don't assert in regime_is_user() for E10 mmuidx values

In regime_is_user() we assert if we're passed an ARMMMUIdx_E10_*
mmuidx value. This used to make sense because we only used this
function in ptw.c and would never use it on this kind of stage 1+2
mmuidx, only for an individual stage 1 or stage 2 mmuidx.

However, when we implemented FEAT_E0PD we added a callsite in
aa64_va_parameters(), which means this can now be called for
stage 1+2 mmuidx values if the guest sets the TCG_ELX.{E0PD0,E0PD1}
bits to enable use of the feature. This will then result in
an assertion failure later, for instance on a TLBI operation:

#6  0x00007ffff6d0e70f in g_assertion_message_expr
    (domain=0x0, file=0x55555676eeba "../../target/arm/internals.h", line=978, 
func=0x555556771d48 <__func__.5> "regime_is_user", expr=<optimised out>)
    at ../../../glib/gtestutils.c:3279
#7  0x0000555555f286d2 in regime_is_user (env=0x555557f2fe00, 
mmu_idx=ARMMMUIdx_E10_0) at ../../target/arm/internals.h:978
#8  0x0000555555f3e31c in aa64_va_parameters (env=0x555557f2fe00, 
va=18446744073709551615, mmu_idx=ARMMMUIdx_E10_0, data=true, el1_is_aa32=false)
    at ../../target/arm/helper.c:12048
#9  0x0000555555f3163b in tlbi_aa64_get_range (env=0x555557f2fe00, 
mmuidx=ARMMMUIdx_E10_0, value=106721347371041) at ../../target/arm/helper.c:5214
#10 0x0000555555f317e8 in do_rvae_write (env=0x555557f2fe00, 
value=106721347371041, idxmap=21, synced=true) at ../../target/arm/helper.c:5260
#11 0x0000555555f31925 in tlbi_aa64_rvae1is_write (env=0x555557f2fe00, 
ri=0x555557fbeae0, value=106721347371041) at ../../target/arm/helper.c:5302
#12 0x0000555556036f8f in helper_set_cp_reg64 (env=0x555557f2fe00, 
rip=0x555557fbeae0, value=106721347371041) at 
../../target/arm/tcg/op_helper.c:965

Since we do know whether these mmuidx values are for usermode
or not, we can easily make regime_is_user() handle them:
ARMMMUIdx_E10_0 is user, and the other two are not.

Cc: [email protected]
Fixes: e4c93e44ab103f ("target/arm: Implement FEAT_E0PD")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1505b651fdbd9af59a4a90876a62ae7ea2d4cd39)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 568190ef60ff69f09939e0ba00843d19fa8b94c9
      
https://github.com/qemu/qemu/commit/568190ef60ff69f09939e0ba00843d19fa8b94c9
  Author: Evgenii Prokopiev <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/riscv/csr.c

  Log Message:
  -----------
  target/riscv/csr.c: Fix an access to VXSAT

The register VXSAT should be RW only to the first bit.
The remaining bits should be 0.

The RISC-V Instruction Set Manual Volume I: Unprivileged Architecture

The vxsat CSR has a single read-write least-significant bit (vxsat[0])
that indicates if a fixed-point instruction has had to saturate an output
value to fit into a destination format. Bits vxsat[XLEN-1:1]
should be written as zeros.

Signed-off-by: Evgenii Prokopiev <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 5a60026cad4e9dba929cab4f63229e4b9110cf0a)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 76e0030636b9c23d11d01e5701cf8197d9068afd
      
https://github.com/qemu/qemu/commit/76e0030636b9c23d11d01e5701cf8197d9068afd
  Author: TANG Tiancheng <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/riscv/cpu.h

  Log Message:
  -----------
  target/riscv: Correct SXL return value for RV32 in RV64 QEMU

Ensure that riscv_cpu_sxl returns MXL_RV32 when runningRV32 in an
RV64 QEMU.

Signed-off-by: TANG Tiancheng <[email protected]>
Fixes: 05e6ca5e156 ("target/riscv: Ignore reserved bits in PTE for RV64")
Reviewed-by: Liu Zhiwei <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 929e4277c128772bad41cc795995f754cb9991af)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 5dbbbaf971c95ec8b32317fd5365f63670a500e8
      
https://github.com/qemu/qemu/commit/5dbbbaf971c95ec8b32317fd5365f63670a500e8
  Author: Sergey Makarov <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M hw/intc/sifive_plic.c

  Log Message:
  -----------
  hw/intc: Don't clear pending bits on IRQ lowering

According to PLIC specification (chapter 5), there
is only one case, when interrupt is claimed. Fix
PLIC controller to match this behavior.

Signed-off-by: Sergey Makarov <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit a84be2baa9eca8bc500f866ad943b8f63dc99adf)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: dc89b2b30077496d5e77cda47215dee5aeae02ce
      
https://github.com/qemu/qemu/commit/dc89b2b30077496d5e77cda47215dee5aeae02ce
  Author: Rob Bradford <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/riscv/cpu.c

  Log Message:
  -----------
  target/riscv: Set vtype.vill on CPU reset

The RISC-V unprivileged specification "31.3.11. State of Vector
Extension at Reset" has a note that recommends vtype.vill be set on
reset as part of ensuring that the vector extension have a consistent
state at reset.

This change now makes QEMU consistent with Spike which sets vtype.vill
on reset.

Signed-off-by: Rob Bradford <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit f8c1f36a2e3dab4935e7c5690e578ac71765766b)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 6e46caa91f84d9c8c73bf46a69e935fb7f541a68
      
https://github.com/qemu/qemu/commit/6e46caa91f84d9c8c73bf46a69e935fb7f541a68
  Author: Anup Patel <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M hw/intc/riscv_aplic.c

  Log Message:
  -----------
  hw/intc/riscv_aplic: Fix in_clrip[x] read emulation

The reads to in_clrip[x] registers return rectified input values of the
interrupt sources.

A rectified input value of an interrupt source is defined by the section
"4.5.2 Source configurations (sourcecfg[1]–sourcecfg[1023])" of the RISC-V
AIA specification as:
"rectified input value = (incoming wire value) XOR (source is inverted)"

Update the riscv_aplic_read_input_word() implementation to match the above.

Fixes: e8f79343cfc8 ("hw/intc: Add RISC-V AIA APLIC device emulation")
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 0678e9f29c2301d0a1afc8d01a78cdfa7ad2ddbd)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 39d858fa23859536fe74d6326535fffa31b6b165
      
https://github.com/qemu/qemu/commit/39d858fa23859536fe74d6326535fffa31b6b165
  Author: Yong-Xuan Wang <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M hw/intc/riscv_aplic.c

  Log Message:
  -----------
  hw/intc/riscv_aplic: Check and update pending when write sourcecfg

The section 4.5.2 of the RISC-V AIA specification says that any write
to a sourcecfg register of an APLIC might (or might not) cause the
corresponding interrupt-pending bit to be set to one if the rectified
input value is high (= 1) under the new source mode.

If an interrupt is asserted before the driver configs its interrupt
type to APLIC, it's pending bit will not be set except a relevant
write to a setip or setipnum register. When we write the interrupt
type to sourcecfg register, if the APLIC device doesn't check
rectified input value and update the pending bit, this interrupt
might never becomes pending.

For APLIC.m, we can manully set pending by setip or setipnum
registers in driver. But for APLIC.w, the pending status totally
depends on the rectified input value, we can't control the pending
status via mmio registers. In this case, hw should check and update
pending status for us when writing sourcecfg registers.

Update QEMU emulation to handle "pre-existing" interrupts.

Signed-off-by: Yong-Xuan Wang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 2ae6cca1d3389801ee72fc5e58c52573218f3514)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: context fixup in hw/intc/riscv_aplic.c)


  Commit: 844ffb357a24ac2fae74d73d60a23be9d1db9821
      
https://github.com/qemu/qemu/commit/844ffb357a24ac2fae74d73d60a23be9d1db9821
  Author: Anton Blanchard <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/riscv/vector_helper.c

  Log Message:
  -----------
  target/riscv: Fix vcompress with rvv_ta_all_1s

vcompress packs vl or less fields into vd, so the tail starts after the
last packed field. This could be more clearly expressed in the ISA,
but for now this thread helps to explain it:

https://github.com/riscv/riscv-v-spec/issues/796

Signed-off-by: Anton Blanchard <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit c128d39edeff337220fc536a3e935bcba01ecb49)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 5c1c138ee767716880a3f316248c884fb9ed3198
      
https://github.com/qemu/qemu/commit/5c1c138ee767716880a3f316248c884fb9ed3198
  Author: Ilya Leoshkevich <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Set ctx->opcode for decode_insn32()

divdu (without a dot) sometimes updates cr0, even though it shouldn't.
The reason is that gen_op_arith_divd() checks Rc(ctx->opcode), which is
not initialized. This field is initialized only for instructions that
go through decode_legacy(), and not decodetree.

There already was a similar issue fixed in commit 86e6202a57b1
("target/ppc: Make divw[u] handler method decodetree compatible.").

It's not immediately clear what else may access the uninitialized
ctx->opcode, so instead of playing whack-a-mole and changing the check
to compute_rc0, simply initialize ctx->opcode.

Cc: [email protected]
Fixes: 99082815f17f ("target/ppc: Add infrastructure for prefixed insns")
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit c9b8a13a8841e0e23901e57e24ea98eeef16cf91)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 67683048becb6f6974bccb10b1bcb9338173c92e
      
https://github.com/qemu/qemu/commit/67683048becb6f6974bccb10b1bcb9338173c92e
  Author: Peter Maydell <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M target/arm/vec_helper.c

  Log Message:
  -----------
  target/arm: Fix SVE SDOT/UDOT/USDOT (4-way, indexed)

Our implementation of the indexed version of SVE SDOT/UDOT/USDOT got
the calculation of the inner loop terminator wrong.  Although we
correctly account for the element size when we calculate the
terminator for the first iteration:
   intptr_t segend = MIN(16 / sizeof(TYPED), opr_sz_n);
we don't do that when we move it forward after the first inner loop
completes.  The intention is that we process the vector in 128-bit
segments, which for a 64-bit element size should mean (1, 2), (3, 4),
(5, 6), etc.  This bug meant that we would iterate (1, 2), (3, 4, 5,
6), (7, 8, 9, 10) etc and apply the wrong indexed element to some of
the operations, and also index off the end of the vector.

You don't see this bug if the vector length is small enough that we
don't need to iterate the outer loop, i.e.  if it is only 128 bits,
or if it is the 64-bit special case from AA32/AA64 AdvSIMD.  If the
vector length is 256 bits then we calculate the right results for the
elements in the vector but do index off the end of the vector. Vector
lengths greater than 256 bits see wrong answers. The instructions
that produce 32-bit results behave correctly.

Fix the recalculation of 'segend' for subsequent iterations, and
restore a version of the comment that was lost in the refactor of
commit 7020ffd656a5 that explains why we only need to clamp segend to
opr_sz_n for the first iteration, not the later ones.

Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2595
Fixes: 7020ffd656a5 ("target/arm: Macroize helper_gvec_{s,u}dot_idx_{b,h}")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit e6b2fa1b81ac6b05c4397237c846a295a9857920)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 8375dadba7c0684a19257d2d6db3a9a01db256e7
      
https://github.com/qemu/qemu/commit/8375dadba7c0684a19257d2d6db3a9a01db256e7
  Author: Klaus Jensen <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M hw/nvme/ctrl.c

  Log Message:
  -----------
  hw/nvme: fix handling of over-committed queues

If a host chooses to use the SQHD "hint" in the CQE to know if there is
room in the submission queue for additional commands, it may result in a
situation where there are not enough internal resources (struct
NvmeRequest) available to process the command. For a lack of a better
term, the host may "over-commit" the device (i.e., it may have more
inflight commands than the queue size).

For example, assume a queue with N entries. The host submits N commands
and all are picked up for processing, advancing the head and emptying
the queue. Regardless of which of these N commands complete first, the
SQHD field of that CQE will indicate to the host that the queue is
empty, which allows the host to issue N commands again. However, if the
device has not posted CQEs for all the previous commands yet, the device
will have less than N resources available to process the commands, so
queue processing is suspended.

And here lies an 11 year latent bug. In the absense of any additional
tail updates on the submission queue, we never schedule the processing
bottom-half again unless we observe a head update on an associated full
completion queue. This has been sufficient to handle N-to-1 SQ/CQ setups
(in the absense of over-commit of course). Incidentially, that "kick all
associated SQs" mechanism can now be killed since we now just schedule
queue processing when we return a processing resource to a non-empty
submission queue, which happens to cover both edge cases. However, we
must retain kicking the CQ if it was previously full.

So, apparently, no previous driver tested with hw/nvme has ever used
SQHD (e.g., neither the Linux NVMe driver or SPDK uses it). But then OSv
shows up with the driver that actually does. I salute you.

Fixes: f3c507adcd7b ("NVMe: Initial commit for new storage interface")
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2388
Reported-by: Waldemar Kozaczuk <[email protected]>
Reviewed-by: Keith Busch <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 9529aa6bb4d18763f5b4704cb4198bd25cbbee31)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e9abc23ef4ea24589f17781eb7d97fd7433db2ca
      
https://github.com/qemu/qemu/commit/e9abc23ef4ea24589f17781eb7d97fd7433db2ca
  Author: Christian Schoenebeck <[email protected]>
  Date:   2024-11-10 (Sun, 10 Nov 2024)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: fix crash on 'Treaddir' request

A bad (broken or malicious) 9p client (guest) could cause QEMU host to
crash by sending a 9p 'Treaddir' request with a numeric file ID (FID) that
was previously opened for a file instead of an expected directory:

  #0  0x0000762aff8f4919 in __GI___rewinddir (dirp=0xf) at
    ../sysdeps/unix/sysv/linux/rewinddir.c:29
  #1  0x0000557b7625fb40 in do_readdir_many (pdu=0x557bb67d2eb0,
    fidp=0x557bb67955b0, entries=0x762afe9fff58, offset=0, maxsize=131072,
    dostat=<optimized out>) at ../hw/9pfs/codir.c:101
  #2  v9fs_co_readdir_many (pdu=pdu@entry=0x557bb67d2eb0,
    fidp=fidp@entry=0x557bb67955b0, entries=entries@entry=0x762afe9fff58,
    offset=0, maxsize=131072, dostat=false) at ../hw/9pfs/codir.c:226
  #3  0x0000557b7625c1f9 in v9fs_do_readdir (pdu=0x557bb67d2eb0,
    fidp=0x557bb67955b0, offset=<optimized out>,
    max_count=<optimized out>) at ../hw/9pfs/9p.c:2488
  #4  v9fs_readdir (opaque=0x557bb67d2eb0) at ../hw/9pfs/9p.c:2602

That's because V9fsFidOpenState was declared as union type. So the
same memory region is used for either an open POSIX file handle (int),
or a POSIX DIR* pointer, etc., so 9p server incorrectly used the
previously opened (valid) POSIX file handle (0xf) as DIR* pointer,
eventually causing a crash in glibc's rewinddir() function.

Root cause was therefore a missing check in 9p server's 'Treaddir'
request handler, which must ensure that the client supplied FID was
really opened as directory stream before trying to access the
aforementioned union and its DIR* member.

Cc: [email protected]
Fixes: d62dbb51f7 ("virtio-9p: Add fidtype so that we can do type ...")
Reported-by: Akihiro Suda <[email protected]>
Tested-by: Akihiro Suda <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 042b4ebfd2298ae01553844124f27d651cdb1071)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: afc87f12b5e85b08dcbabe60fffdbba5b8e9545e
      
https://github.com/qemu/qemu/commit/afc87f12b5e85b08dcbabe60fffdbba5b8e9545e
  Author: Alexander Graf <[email protected]>
  Date:   2024-11-13 (Wed, 13 Nov 2024)

  Changed paths:
    M target/i386/cpu.h
    M target/i386/tcg/seg_helper.c
    M target/i386/tcg/sysemu/excp_helper.c

  Log Message:
  -----------
  target/i386: Fix legacy page table walk

Commit b56617bbcb4 ("target/i386: Walk NPT in guest real mode") added
logic to run the page table walker even in real mode if we are in NPT
mode.  That function then determined whether real mode or paging is
active based on whether the pg_mode variable was 0.

Unfortunately pg_mode is 0 in two situations:

  1) Paging is disabled (real mode)
  2) Paging is in 2-level paging mode (32bit without PAE)

That means the walker now assumed that 2-level paging mode was real
mode, breaking NetBSD as well as Windows XP.

To fix that, this patch adds a new PG flag to pg_mode which indicates
whether paging is active at all and uses that to determine whether we
are in real mode or not.

Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2654
Fixes: b56617bbcb4 ("target/i386: Walk NPT in guest real mode")
Fixes: 253c0a06e03 (commit b56617bbcb4 in stable-7.2.x series)
Signed-off-by: Alexander Graf <[email protected]>
Reported-by: Mark Cave-Ayland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 8fa11a4df344f58375eb26b3b65004345f21ef37)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d52746b10102bf0217d72f92d4d579a588fc7227
      
https://github.com/qemu/qemu/commit/d52746b10102bf0217d72f92d4d579a588fc7227
  Author: Helge Deller <[email protected]>
  Date:   2024-11-17 (Sun, 17 Nov 2024)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: Fix setreuid and setregid to use direct syscalls

The commit fd6f7798ac30 ("linux-user: Use direct syscalls for setuid(),
etc") added direct syscall wrappers for setuid(), setgid(), etc since the
system calls have different semantics than the libc functions.

Add and use the corresponding wrappers for setreuid and setregid which
were missed in that commit.

This fixes the build of the debian package of the uid_wrapper library
(https://cwrap.org/uid_wrapper.html) when running linux-user.

Cc: [email protected]
Signed-off-by: Helge Deller <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Ilya Leoshkevich <[email protected]>
Message-ID: <Zyo2jMKqq8hG8Pkz@p100>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8491026a08b417b2d4070f7c373dcb43134c5312)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: b661eea97fe14b137a3b443f4c5dd321fa8dd8ee
      
https://github.com/qemu/qemu/commit/b661eea97fe14b137a3b443f4c5dd321fa8dd8ee
  Author: Richard Henderson <[email protected]>
  Date:   2024-11-17 (Sun, 17 Nov 2024)

  Changed paths:
    M target/arm/sve_helper.c

  Log Message:
  -----------
  target/arm: Drop user-only special case in sve_stN_r

This path is reachable with plugins enabled, and provoked
with run-plugin-catch-syscalls-with-libinline.so.

Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit f27550804688da43c6e0d87b2f9e143adbf76271)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 52558d49d6926a22fe2a0bf986a9c7cff6283ff2
      
https://github.com/qemu/qemu/commit/52558d49d6926a22fe2a0bf986a9c7cff6283ff2
  Author: Peter Maydell <[email protected]>
  Date:   2024-11-17 (Sun, 17 Nov 2024)

  Changed paths:
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Allow top bit of SIMD_DATA_BITS to be set in simd_desc()

In simd_desc() we create a SIMD descriptor from various pieces
including an arbitrary data value from the caller.  We try to
sanitize these to make sure everything will fit: the 'data' value
needs to fit in the SIMD_DATA_BITS (== 22) sized field.  However we
do that sanitizing with:
   tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS));

This works for the case where the data is supposed to be considered
as a signed integer (which can then be returned via simd_data()).
However, some callers want to treat the data value as unsigned.

Specifically, for the Arm SVE operations, make_svemte_desc()
assembles a data value as a collection of fields, and it needs to use
all 22 bits.  Currently if MTE is enabled then its MTEDESC SIZEM1
field may have the most significant bit set, and then it will trip
this assertion.

Loosen the assertion so that we only check that the data value will
fit into the field in some way, either as a signed or as an unsigned
value.  This means we will fail to detect some kinds of bug in the
callers, but we won't spuriously assert for intentional use of the
data field as unsigned.

Cc: [email protected]
Fixes: db432672dc50e ("tcg: Add generic vector expanders")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2601
Signed-off-by: Peter Maydell <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8377e3fb854d126ba10e61cb6b60885af8443ad4)
Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/64d9173a0291...52558d49d692

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications


Reply via email to