qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 358dd2: docs/conf.py: Remove usage of distuti


From: Yong-Xuan Wang
Subject: [Qemu-commits] [qemu/qemu] 358dd2: docs/conf.py: Remove usage of distutils
Date: Wed, 27 Mar 2024 03:21:53 -0700

  Branch: refs/heads/staging-8.2
  Home:   https://github.com/qemu/qemu
  Commit: 358dd25fb011f5441617570b597e10a71cb8177c
      
https://github.com/qemu/qemu/commit/358dd25fb011f5441617570b597e10a71cb8177c
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2024-03-22 (Fri, 22 Mar 2024)

  Changed paths:
    M docs/conf.py

  Log Message:
  -----------
  docs/conf.py: Remove usage of distutils

The macOS jobs in our CI recently started failing, complaining that
the distutils module is not available anymore. And indeed, according to
https://peps.python.org/pep-0632/ it's been deprecated since a while
and now likely got removed in recent Python versions.

Fortunately, we only use it for a version check via LooseVersion here
which we don't really need anymore - according to Repology.org, these
are the versions of sphinx-rtd-theme that are currently used by the
various distros:

 centos_stream_8: 0.3.1
 centos_stream_9: 0.5.1
 fedora_38: 1.1.1
 fedora_39: 1.2.2
 freebsd: 1.0.0
 haikuports_master: 1.2.1
 openbsd: 1.2.2
 opensuse_leap_15_5: 0.5.1
 pkgsrc_current: 2.0.0
 debian_11: 0.5.1
 debian_12: 1.2.0
 ubuntu_20_04: 0.4.3
 ubuntu_22_04: 1.0.0
 ubuntu_24_04: 2.0.0

So except for CentOS 8, all distros are using a newer version of
sphinx-rtd-theme, and for CentOS 8 we don't support compiling with
the Sphinx of the distro anymore anyway, since it's based on the
Python 3.6 interpreter there. For compiling on CentOS 8, you have
to use the alternative Python 3.8 interpreter which comes without
Sphinx, so that needs the Sphinx installed via pip in the venv
instead, and that is using a newer version, too, according to our
pythondeps.toml file.

Thus we can simply drop the version check now to get rid of the
distutils dependency here.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 20240304130403.129543-1-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit eb844330bd36ebdd4959053da08069d1e5d49119)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: ef9b43bb8e2daf02e72c5014c4307f495d229544
      
https://github.com/qemu/qemu/commit/ef9b43bb8e2daf02e72c5014c4307f495d229544
  Author: Song Gao <gaosong@loongson.cn>
  Date:   2024-03-25 (Mon, 25 Mar 2024)

  Changed paths:
    M target/loongarch/cpu.c

  Log Message:
  -----------
  target/loongarch: Fix qemu-system-loongarch64 assert failed with the option 
'-d int'

qemu-system-loongarch64 assert failed with the option '-d int',
the helper_idle() raise an exception EXCP_HLT, but the exception name is 
undefined.

Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20240321123606.1704900-1-gaosong@loongson.cn>
(cherry picked from commit 1590154ee4376819a8c6ee61e849ebf4a4e7cd02)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 784ebe52bdb66108a9258800f6711ec14e6a5f54
      
https://github.com/qemu/qemu/commit/784ebe52bdb66108a9258800f6711ec14e6a5f54
  Author: Ido Plat <ido.plat@ibm.com>
  Date:   2024-03-25 (Mon, 25 Mar 2024)

  Changed paths:
    M target/s390x/tcg/translate.c

  Log Message:
  -----------
  target/s390x: Use mutable temporary value for op_ts

Otherwise TCG would assume the register that holds t1 would be constant
and reuse whenever it needs the value within it.

Cc: qemu-stable@nongnu.org
Fixes: f1ea739bd598 ("target/s390x: Use tcg_constant_* in local contexts")
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[iii: Adjust a newline and capitalization, add tags]
Signed-off-by: Ido Plat <ido.plat@ibm.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-ID: <20240318202722.20675-1-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 272fba9779af0bb1c29cd30302fc1e31c59274d0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 73d604a4bc5641d38680dbac3e90e368db9549a3
      
https://github.com/qemu/qemu/commit/73d604a4bc5641d38680dbac3e90e368db9549a3
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M hw/net/vhost_net.c
    M hw/virtio/trace-events
    M hw/virtio/vdpa-dev.c
    M hw/virtio/vhost-vdpa.c
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vdpa-dev: Fix initialisation order to restore VDUSE compatibility

VDUSE requires that virtqueues are first enabled before the DRIVER_OK
status flag is set; with the current API of the kernel module, it is
impossible to enable the opposite order in our block export code because
userspace is not notified when a virtqueue is enabled.

This requirement also mathces the normal initialisation order as done by
the generic vhost code in QEMU. However, commit 6c482547 accidentally
changed the order for vdpa-dev and broke access to VDUSE devices with
this.

This changes vdpa-dev to use the normal order again and use the standard
vhost callback .vhost_set_vring_enable for this. VDUSE devices can be
used with vdpa-dev again after this fix.

vhost_net intentionally avoided enabling the vrings for vdpa and does
this manually later while it does enable them for other vhost backends.
Reflect this in the vhost_net code and return early for vdpa, so that
the behaviour doesn't change for this device.

Cc: qemu-stable@nongnu.org
Fixes: 6c4825476a43 ('vdpa: move vhost_vdpa_set_vring_ready to the caller')
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240315155949.86066-1-kwolf@redhat.com>
Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2c66de61f88dc9620a32239f7dd61524a57f66b0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 80ccf1e4856dd1c02a38d7ce72bbf2b31ea5ab95
      
https://github.com/qemu/qemu/commit/80ccf1e4856dd1c02a38d7ce72bbf2b31ea5ab95
  Author: Stefan Reiter <s.reiter@proxmox.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block/io: accept NULL qiov in bdrv_pad_request

Some operations, e.g. block-stream, perform reads while discarding the
results (only copy-on-read matters). In this case, they will pass NULL
as the target QEMUIOVector, which will however trip bdrv_pad_request,
since it wants to extend its passed vector. In particular, this is the
case for the blk_co_preadv() call in stream_populate().

If there is no qiov, no operation can be done with it, but the bytes
and offset still need to be updated, so the subsequent aligned read
will actually be aligned and not run into an assertion failure.

In particular, this can happen when the request alignment of the top
node is larger than the allocated part of the bottom node, in which
case padding becomes necessary. For example:

> ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M -o cluster_size=32768
> ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2
> ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev 
> qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "blockdev-add", "arguments": { "driver": "compress", "file": 
> "node0", "node-name": "node1" } }
> {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": 
> "node1" } }
> EOF

Originally-by: Stefan Reiter <s.reiter@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
[FE: do update bytes and offset in any case
     add reproducer to commit message]
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20240322095009.346989-2-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3f934817c82c2f1bf1c238f8d1065a3be10a3c9e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 1652e5b97f1c41aa433b76365d220dc69f27cf37
      
https://github.com/qemu/qemu/commit/1652e5b97f1c41aa433b76365d220dc69f27cf37
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M block/block-backend.c

  Log Message:
  -----------
  block-backend: fix edge case in bdrv_next() where BDS associated to BB changes

The old_bs variable in bdrv_next() is currently determined by looking
at the old block backend. However, if the block graph changes before
the next bdrv_next() call, it might be that the associated BDS is not
the same that was referenced previously. In that case, the wrong BDS
is unreferenced, leading to an assertion failure later:

> bdrv_unref: Assertion `bs->refcnt > 0' failed.

In particular, this can happen in the context of bdrv_flush_all(),
when polling for bdrv_co_flush() in the generated co-wrapper leads to
a graph change (for example with a stream block job [0]).

A racy reproducer:

> #!/bin/bash
> rm -f /tmp/backing.qcow2
> rm -f /tmp/top.qcow2
> ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M
> ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2
> ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev 
> qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": 
> "node0" } }
> {"execute": "quit"}
> EOF

[0]:

> #0  bdrv_replace_child_tran (child=..., new_bs=..., tran=...)
> #1  bdrv_replace_node_noperm (from=..., to=..., auto_skip=..., tran=..., 
> errp=...)
> #2  bdrv_replace_node_common (from=..., to=..., auto_skip=..., 
> detach_subchain=..., errp=...)
> #3  bdrv_drop_filter (bs=..., errp=...)
> #4  bdrv_cor_filter_drop (cor_filter_bs=...)
> #5  stream_prepare (job=...)
> #6  job_prepare_locked (job=...)
> #7  job_txn_apply_locked (fn=..., job=...)
> #8  job_do_finalize_locked (job=...)
> #9  job_exit (opaque=...)
> #10 aio_bh_poll (ctx=...)
> #11 aio_poll (ctx=..., blocking=...)
> #12 bdrv_poll_co (s=...)
> #13 bdrv_flush (bs=...)
> #14 bdrv_flush_all ()
> #15 do_vm_stop (state=..., send_stop=...)
> #16 vm_shutdown ()

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20240322095009.346989-3-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit f6d38c9f6dae6fce99dcaf6ca16a1fe5b5e19c4c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: edba203229fd1688f59895a778029831c0905c2f
      
https://github.com/qemu/qemu/commit/edba203229fd1688f59895a778029831c0905c2f
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M block/block-backend.c

  Log Message:
  -----------
  block-backend: fix edge case in bdrv_next_cleanup() where BDS associated to 
BB changes

Same rationale as for commit "block-backend: fix edge case in
bdrv_next() where BDS associated to BB changes". The block graph might
change between the bdrv_next() call and the bdrv_next_cleanup() call,
so it could be that the associated BDS is not the same that was
referenced previously anymore. Instead, rely on bdrv_next() to set
it->bs to the BDS it referenced and unreference that one in any case.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20240322095009.346989-4-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit bac09b093ebbb79e6a7444c7b979c32ca5540132)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: eaa20895b7a1b5a86b9563327763c8fe6ea35d8d
      
https://github.com/qemu/qemu/commit/eaa20895b7a1b5a86b9563327763c8fe6ea35d8d
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    A tests/qemu-iotests/tests/stream-unaligned-prefetch
    A tests/qemu-iotests/tests/stream-unaligned-prefetch.out

  Log Message:
  -----------
  iotests: add test for stream job with an unaligned prefetch read

Previously, bdrv_pad_request() could not deal with a NULL qiov when
a read needed to be aligned. During prefetch, a stream job will pass a
NULL qiov. Add a test case to cover this scenario.

By accident, also covers a previous race during shutdown, where block
graph changes during iteration in bdrv_flush_all() could lead to
unreferencing the wrong block driver state and an assertion failure
later.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20240322095009.346989-5-f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 12d7b3bbd3333cededd3b695501d8d247239d769)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 78bebf86926ca8595d35f7c40e242997b08c5bc6
      
https://github.com/qemu/qemu/commit/78bebf86926ca8595d35f7c40e242997b08c5bc6
  Author: Gregory Price <gregory.price@memverge.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

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

  Log Message:
  -----------
  target/i386/tcg: Enable page walking from MMIO memory

CXL emulation of interleave requires read and write hooks due to
requirement for subpage granularity. The Linux kernel stack now enables
using this memory as conventional memory in a separate NUMA node. If a
process is deliberately forced to run from that node
$ numactl --membind=1 ls
the page table walk on i386 fails.

Useful part of backtrace:

    (cpu=cpu@entry=0x555556fd9000, fmt=fmt@entry=0x555555fe3378 
"cpu_io_recompile: could not find TB for pc=%p")
    at ../../cpu-target.c:359
    (retaddr=0, addr=19595792376, attrs=..., xlat=<optimized out>, 
cpu=0x555556fd9000, out_offset=<synthetic pointer>)
    at ../../accel/tcg/cputlb.c:1339
    (cpu=0x555556fd9000, full=0x7fffee0d96e0, ret_be=ret_be@entry=0, 
addr=19595792376, size=size@entry=8, mmu_idx=4, type=MMU_DATA_LOAD, ra=0) at 
../../accel/tcg/cputlb.c:2030
    (cpu=cpu@entry=0x555556fd9000, p=p@entry=0x7ffff56fddc0, mmu_idx=<optimized 
out>, type=type@entry=MMU_DATA_LOAD, memop=<optimized out>, ra=ra@entry=0) at 
../../accel/tcg/cputlb.c:2356
    (cpu=cpu@entry=0x555556fd9000, addr=addr@entry=19595792376, oi=oi@entry=52, 
ra=ra@entry=0, access_type=access_type@entry=MMU_DATA_LOAD) at 
../../accel/tcg/cputlb.c:2439
    at ../../accel/tcg/ldst_common.c.inc:301
    at ../../target/i386/tcg/sysemu/excp_helper.c:173
    (err=0x7ffff56fdf80, out=0x7ffff56fdf70, mmu_idx=0, 
access_type=MMU_INST_FETCH, addr=18446744072116178925, env=0x555556fdb7c0)
    at ../../target/i386/tcg/sysemu/excp_helper.c:578
    (cs=0x555556fd9000, addr=18446744072116178925, size=<optimized out>, 
access_type=MMU_INST_FETCH, mmu_idx=0, probe=<optimized out>, retaddr=0) at 
../../target/i386/tcg/sysemu/excp_helper.c:604

Avoid this by plumbing the address all the way down from
x86_cpu_tlb_fill() where is available as retaddr to the actual accessors
which provide it to probe_access_full() which already handles MMIO accesses.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2180
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2220
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Gregory Price <gregory.price@memverge.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-ID: <20240307155304.31241-2-Jonathan.Cameron@huawei.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 9dab7bbb017d11b64c52239fa4e2f910a6a004f2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 783b2fc0a93953be2dd115aeb7bf0333d1eb704a
      
https://github.com/qemu/qemu/commit/783b2fc0a93953be2dd115aeb7bf0333d1eb704a
  Author: Lorenz Brun <lorenz@brun.one>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M hw/scsi/scsi-generic.c

  Log Message:
  -----------
  hw/scsi/scsi-generic: Fix io_timeout property not applying

The io_timeout property, introduced in c9b6609 (part of 6.0) is
silently overwritten by the hardcoded default value of 30 seconds
(DEFAULT_IO_TIMEOUT) in scsi_generic_realize because that function is
being called after the properties have already been applied.

The property definition already has a default value which is applied
correctly when no value is explicitly set, so we can just remove the
code which overrides the io_timeout completely.

This has been tested by stracing SG_IO operations with the io_timeout
property set and unset and now sets the timeout field in the ioctl
request to the proper value.

Fixes: c9b6609b69facad ("scsi: make io_timeout configurable")
Signed-off-by: Lorenz Brun <lorenz@brun.one>
Message-ID: <20240315145831.2531695-1-lorenz@brun.one>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 7c7a9f578e4fb1adff7ac8d9acaaaedb87474e76)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 0041b5a0140a9ed3984e66919fc4227ac4e23f75
      
https://github.com/qemu/qemu/commit/0041b5a0140a9ed3984e66919fc4227ac4e23f75
  Author: Yao Xingtao <yaoxt.fnst@fujitsu.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M monitor/hmp-cmds-target.c

  Log Message:
  -----------
  monitor/hmp-cmds-target: Append a space in error message in gpa2hva()

In qemu monitor mode, when we use gpa2hva command to print the host
virtual address corresponding to a guest physical address, if the gpa is
not in RAM, the error message is below:

  (qemu) gpa2hva 0x750000000
  Memory at address 0x750000000is not RAM

A space is missed between '0x750000000' and 'is'.

Signed-off-by: Yao Xingtao <yaoxt.fnst@fujitsu.com>
Fixes: e9628441df ("hmp: gpa2hva and gpa2hpa hostaddr command")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Message-ID: <20240319021610.2423844-1-ruansy.fnst@fujitsu.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit a158c63b3ba120f1656e4dd815d186c623fb5ef6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: bf26b6acc158d30dfb965f664bb767a4b0176a19
      
https://github.com/qemu/qemu/commit/bf26b6acc158d30dfb965f664bb767a4b0176a19
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/vector_helper.c

  Log Message:
  -----------
  target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX()

The helper isn't setting env->vstart = 0 after its execution, as it is
expected from every vector instruction that completes successfully.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Message-ID: <20240314175704.478276-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit d3646e31ce6d1e02e46e6eabdbc2e637c0cbece7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 9f0db88ca97aa991eb107a4435494feaef3541ca
      
https://github.com/qemu/qemu/commit/9f0db88ca97aa991eb107a4435494feaef3541ca
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc

  Log Message:
  -----------
  trans_rvv.c.inc: set vstart = 0 in int scalar move insns

trans_vmv_x_s, trans_vmv_s_x, trans_vfmv_f_s and trans_vfmv_s_f aren't
setting vstart = 0 after execution. This is usually done by a helper in
vector_helper.c but these functions don't use helpers.

We'll set vstart after any potential 'over' brconds, and that will also
mandate a mark_vs_dirty() too.

Fixes: dedc53cbc9 ("target/riscv: rvv-1.0: integer scalar move instructions")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240314175704.478276-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 0848f7c18ef50de9f955e7eeb4363d92766a41bf)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 693ceca98789e9ea39af2bce644a56d142f3d72b
      
https://github.com/qemu/qemu/commit/693ceca98789e9ea39af2bce644a56d142f3d72b
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/vector_helper.c

  Log Message:
  -----------
  target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess

vmvr_v isn't handling the case where the host might be big endian and
the bytes to be copied aren't sequential.

Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240314175704.478276-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 768e7b329c0be22035da077fe76221dd0a47103b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 43ca6c1a9bac7377076aeb0952d5dfc1a25b8514
      
https://github.com/qemu/qemu/commit/43ca6c1a9bac7377076aeb0952d5dfc1a25b8514
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/insn_trans/trans_rvv.c.inc
    M target/riscv/vector_helper.c

  Log Message:
  -----------
  target/riscv: always clear vstart in whole vec move insns

These insns have 2 paths: we'll either have vstart already cleared if
vstart_eq_zero or we'll do a brcond to check if vstart >= maxsz to call
the 'vmvr_v' helper. The helper will clear vstart if it executes until
the end, or if vstart >= vl.

For starters, the check itself is wrong: we're checking vstart >= maxsz,
when in fact we should use vstart in bytes, or 'startb' like 'vmvr_v' is
calling, to do the comparison. But even after fixing the comparison we'll
still need to clear vstart in the end, which isn't happening too.

We want to make the helpers responsible to manage vstart, including
these corner cases, precisely to avoid these situations:

- remove the wrong vstart >= maxsz cond from the translation;
- add a 'startb >= maxsz' cond in 'vmvr_v', and clear vstart if that
  happens.

This way we're now sure that vstart is being cleared in the end of the
execution, regardless of the path taken.

Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240314175704.478276-5-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 7e53e3ddf6dff200098e112c5370ab16d2d5dbd1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: c4ed8c5610984e77a8bbf30e11b4a45a49a5c239
      
https://github.com/qemu/qemu/commit/c4ed8c5610984e77a8bbf30e11b4a45a49a5c239
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/vcrypto_helper.c
    M target/riscv/vector_helper.c
    M target/riscv/vector_internals.c
    M target/riscv/vector_internals.h

  Log Message:
  -----------
  target/riscv/vector_helpers: do early exit when vstart >= vl

We're going to make changes that will required each helper to be
responsible for the 'vstart' management, i.e. we will relieve the
'vstart < vl' assumption that helpers have today.

Helpers are usually able to deal with vstart >= vl, i.e. doing nothing
aside from setting vstart = 0 at the end, but the tail update functions
will update the tail regardless of vstart being valid or not. Unifying
the tail update process in a single function that would handle the
vstart >= vl case isn't trivial (see [1] for more info).

This patch takes a blunt approach: do an early exit in every single
vector helper if vstart >= vl, unless the helper is guarded with
vstart_eq_zero in the translation. For those cases the helper is ready
to deal with cases where vl might be zero, i.e. throwing exceptions
based on it like vcpop_m() and first_m().

Helpers that weren't changed:

- vcpop_m(), vfirst_m(), vmsetm(), GEN_VEXT_VIOTA_M(): these are guarded
  directly with vstart_eq_zero;

- GEN_VEXT_VCOMPRESS_VM(): guarded with vcompress_vm_check() that checks
  vstart_eq_zero;

- GEN_VEXT_RED(): guarded with either reduction_check() or
  reduction_widen_check(), both check vstart_eq_zero;

- GEN_VEXT_FRED(): guarded with either freduction_check() or
  freduction_widen_check(), both check vstart_eq_zero.

Another exception is vext_ldst_whole(), who operates on effective vector
length regardless of the current settings in vtype and vl.

[1] 
https://lore.kernel.org/qemu-riscv/1590234b-0291-432a-a0fa-c5a6876097bc@linux.alibaba.com/

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240314175704.478276-7-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit df4252b2ecaf93b601109373a17427d1867046e8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: b7ff2c5600fca7e4b8103a03d64281c3133d7c69
      
https://github.com/qemu/qemu/commit/b7ff2c5600fca7e4b8103a03d64281c3133d7c69
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/vector_helper.c

  Log Message:
  -----------
  target/riscv/vector_helper.c: optimize loops in ldst helpers

Change the for loops in ldst helpers to do a single increment in the
counter, and assign it env->vstart, to avoid re-reading from vstart
every time.

Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240314175704.478276-11-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 0a11629c915f61df798919db51a18ffe4649cb65)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6c49ccaaba96507bbee42234662fbe2ed447ce57
      
https://github.com/qemu/qemu/commit/6c49ccaaba96507bbee42234662fbe2ed447ce57
  Author: Frank Chang <frank.chang@sifive.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M hw/intc/riscv_aplic.c

  Log Message:
  -----------
  hw/intc: Update APLIC IDC after claiming iforce register

Currently, QEMU only sets the iforce register to 0 and returns early
when claiming the iforce register. However, this may leave mip.meip
remains at 1 if a spurious external interrupt triggered by iforce
register is the only pending interrupt to be claimed, and the interrupt
cannot be lowered as expected.

This commit fixes this issue by calling riscv_aplic_idc_update() to
update the IDC status after the iforce register is claimed.

Signed-off-by: Frank Chang <frank.chang@sifive.com>
Reviewed-by: Jim Shu <jim.shu@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240321104951.12104-1-frank.chang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 078189b327ae5c5727b51ec714d9663b1d0ca3df)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: dc2abb61afe9dabca66eeb811814077f13eccee6
      
https://github.com/qemu/qemu/commit/dc2abb61afe9dabca66eeb811814077f13eccee6
  Author: Max Chou <max.chou@sifive.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin

According to the Zvfbfmin definition in the RISC-V BF16 extensions spec,
the Zvfbfmin extension only requires either the V extension or the
Zve32f extension.

Signed-off-by: Max Chou <max.chou@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240321170929.1162507-1-max.chou@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit c9b07fe14d3525cd3f2fc01f46eeb3d4ed7c3603)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 38f36fc56855de889c1569d02a238867253aac21
      
https://github.com/qemu/qemu/commit/38f36fc56855de889c1569d02a238867253aac21
  Author: Irina Ryapolova <irina.ryapolova@syntacore.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M target/riscv/cpu_helper.c

  Log Message:
  -----------
  target/riscv: Fix mode in riscv_tlb_fill

Need to convert mmu_idx to privilege mode for PMP function.

Signed-off-by: Irina Ryapolova <irina.ryapolova@syntacore.com>
Fixes: b297129ae1 ("target/riscv: propagate PMP permission to TLB page")
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240320172828.23965-1-irina.ryapolova@syntacore.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit e06adebb08325c39e4c9b652139426c10f021abb)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 1e4ec0958ec734ed6a194475e699c917ba950cb2
      
https://github.com/qemu/qemu/commit/1e4ec0958ec734ed6a194475e699c917ba950cb2
  Author: Yong-Xuan Wang <yongxuan.wang@sifive.com>
  Date:   2024-03-27 (Wed, 27 Mar 2024)

  Changed paths:
    M hw/riscv/virt.c
    M target/riscv/kvm/kvm-cpu.c
    M target/riscv/kvm/kvm_riscv.h

  Log Message:
  -----------
  target/riscv/kvm: fix timebase-frequency when using KVM acceleration

The timebase-frequency of guest OS should be the same with host
machine. The timebase-frequency value in DTS should be got from
hypervisor when using KVM acceleration.

Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Message-ID: <20240314061510.9800-1-yongxuan.wang@sifive.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix due to missing other changes in this area in 8.2.x)


Compare: https://github.com/qemu/qemu/compare/5b51920fbd28...1e4ec0958ec7

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



reply via email to

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