Re: [PATCH for 8.0] qemu/osdep: Switch position of "extern" and "G_NORETURN"

+ Thomas, Daniel (gitlab issue) and Stefan (Windows) Am 18. März 2023 18:59:31 UTC schrieb Bernhard Beschow : >Fixes the Windows build under msys2 using GCC 12 which fails with the following >error: > > [184/579] Compiling C++ object qga/vss-win32/qga-vss.dll.p/install.cpp.obj > FAILED:

[PATCH for-8.1 v3 02/26] target/riscv/cpu.c: remove set_vext_version()

This setter is doing nothing else but setting env->vext_ver. Assign the value directly. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 18591aa53a..2752efe1eb

[PATCH for-8.1 v3 23/26] target/riscv: rework write_misa()

write_misa() must use as much common logic as possible. We want to open code just the bits that are exclusive to the CSR write operation and TCG internals. Rewrite write_misa() to work as follows: - mask the write using misa_ext_mask to avoid enabling unsupported extensions; - suppress RVC if

[PATCH for-8.1 v3 09/26] target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()

We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should

[PATCH for-8.1 v3 06/26] target/riscv/cpu.c: add riscv_cpu_validate_misa_mxl()

Let's remove more code that is open coded in riscv_cpu_realize() and put it into a helper. Let's also add an error message instead of just asserting out if env->misa_mxl_max != env->misa_mlx. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 51

[PATCH for-8.1 v3 11/26] target/riscv/cpu.c: set cpu config in set_misa()

set_misa() is setting all 'misa' related env states and nothing else. But other functions, namely riscv_cpu_validate_set_extensions(), uses the config object to do its job. This creates a need to set the single letter extensions in the cfg object to keep both in sync. At this moment this is being

[PATCH for-8.1 v3 07/26] target/riscv: move pmp and epmp validations to validate_set_extensions()

In the near future, write_misa() will use a variation of what we have now as riscv_cpu_validate_set_extensions(). The pmp and epmp validation will be required in write_misa() and it's already required here in riscv_cpu_realize(), so move it to riscv_cpu_validate_set_extensions(). Signed-off-by:

[PATCH for-8.1 v3 19/26] target/riscv: write env->misa_ext* in register_generic_cpu_props()

In the process of creating the user-facing flags in register_generic_cpu_props() we're also setting default values for the cpu->cfg flags that represents MISA bits. Leaving it as is will cause a discrepancy between users of this function (at this moment the non-named CPUs) and named CPUs. Named

[PATCH for-8.1 v3 22/26] target/riscv: use misa_ext val in riscv_cpu_validate_extensions()

Similar to what we did with riscv_cpu_validate_misa_ext(), let's read all MISA bits from a misa_ext val instead of reading from the cpu->cfg object. This will allow write_misa() to use riscv_cpu_validate_extensions(). Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 25

[PATCH for-8.1 v3 20/26] target/riscv: make validate_misa_ext() use a misa_ext val

We have all MISA specific validations in riscv_cpu_validate_misa_ext(), and we have a guarantee that env->misa_ext will always be in sync with cpu->cfg at this point during realize time, so let's convert it to use a 'misa_ext' parameter instead of reading cpu->cfg. This will prepare the function

[PATCH for-8.1 v3 01/26] target/riscv/cpu.c: add riscv_cpu_validate_v()

The RVV verification will error out if fails and it's being done at the end of riscv_cpu_validate_set_extensions(). Let's put it in its own function and do it earlier. We'll move it out of riscv_cpu_validate_set_extensions() in the near future, but for now this is enough to clean the code a bit.

[PATCH for-8.1 v3 14/26] target/riscv: add RVG

The 'G' bit in misa_ext is a virtual extension that enables a set of extensions (i, m, a, f, d, icsr and ifencei). We're already have code to handle it but no bit definition. Add it. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 4 target/riscv/cpu.h | 1 + 2 files

[PATCH for-8.1 v3 21/26] target/riscv: split riscv_cpu_validate_set_extensions()

We're now ready to split riscv_cpu_validate_set_extensions() in two. None of these steps are going to touch env->misa_ext*. riscv_cpu_validate_extensions() will take care of all validations based on cpu->cfg values. cpu->cfg changes that are required for the validation are being tolerated here.

[PATCH for-8.1 v3 00/26] target/riscv: rework CPU extensions validation

Hi, This new version contains changes suggested by Weiwei Li. I've also reworked write_misa() to cover more cases. write_misa() is now able to properly enable RVG, RVV and RVE. A more in-depth description of what was attempted here can be found in [1]. Note that the current validation flow

[PATCH for-8.1 v3 12/26] target/riscv/cpu.c: redesign register_cpu_props()

Now that the function is a no-op if 'env.misa_ext != 0', and no one that are setting misa_ext != 0 is calling it because set_misa() is setting the cpu cfg accordingly, remove the now deprecated code and rename the function to register_generic_cpu_props(). This function is now doing exactly what

[PATCH for-8.1 v3 18/26] target/riscv: error out on priv failure for RVH

riscv_cpu_disable_priv_spec_isa_exts(), at the end of riscv_cpu_validate_set_extensions(), will disable cpu->cfg.ext_h and cpu->cfg.ext_v if priv_ver check fails. This check can be done in riscv_cpu_validate_misa_ext(). The difference here is that we're not silently disable it: we'll error out.

[PATCH for-8.1 v3 17/26] target/riscv: move riscv_cpu_validate_v() to validate_misa_ext()

riscv_cpu_validate_v() consists of checking RVV related attributes, such as vlen and elen, and setting env->vext_spec. This can be done during riscv_cpu_validate_misa_ext() time, allowing us to fail earlier if RVV constrains are not met. Signed-off-by: Daniel Henrique Barboza ---

[PATCH for-8.1 v3 16/26] target/riscv/cpu.c: add riscv_cpu_validate_misa_ext()

Even after taking RVG off from riscv_cpu_validate_set_extensions(), the function is still doing too much. It is validating misa bits, then validating named extensions, and if the validation succeeds it's doing more changes in both cpu->cfg and MISA bits. It works for the support we have today,

[PATCH for-8.1 v3 26/26] target/riscv: allow write_misa() to enable RVV

Allow write_misa() to enable RVV like we did with RVG. We'll need a riscv_cpu_enable_v() to enable all related misa bits and Z extensions. This new helper validates the existing 'env' conf by using the existing riscv_cpu_validate_v(). We'll also check if we'll be able to enable 'F' by checking for

[PATCH for-8.1 v3 25/26] target/riscv: allow write_misa() to enable RVG

Allow write_misa() to enable RVG by changing riscv_cpu_enable_g() slighty: instead of returning void, return the current env->misa_ext value. This is then retrieved by 'val', which will add the RVG flag itself, and then we'll skip validation and go right into commiting the changes. The reason why

[PATCH for-8.1 v3 05/26] target/riscv/cpu.c: add priv_spec validate/disable_exts helpers

We're doing env->priv_spec validation and assignment at the start of riscv_cpu_realize(), which is fine, but then we're doing a force disable on extensions that aren't compatible with the priv version. This second step is being done too early. The disabled extensions might be re-enabled again in

[PATCH for-8.1 v3 15/26] target/riscv/cpu.c: split RVG code from validate_set_extensions()

We can set all RVG related extensions during realize time, before validate_set_extensions() itself. Put it in a separated function so the validate function already uses the updated state. Note that we're adding an extra constraint: ext_zfinx is a blocker for F, which is a requirement to enable G.

[PATCH for-8.1 v3 24/26] target/riscv: update cpu->cfg misa bits in commit_cpu_cfg()

write_misa() is able to use the same validation workflow riscv_cpu_realize() uses. But it's still not capable of updating cpu->cfg misa props yet. We have no way of blocking future (and current) code from checking env->misa_ext (via riscv_has_ext()) or reading cpu->cfg directly, so our best

[PATCH for-8.1 v3 13/26] target/riscv: put env->misa_ext <-> cpu->cfg code into helpers

The extremely tedious code that sets cpu->cfg based on misa_ext, and vice-versa, is scattered around riscv_cpu_validate_set_extensions() and set_misa(). Introduce helpers to do this work, cleaning up the logic of both functions a bit. While we're at it, add a note in cpu.h informing that any

[PATCH for-8.1 v3 04/26] target/riscv: add PRIV_VERSION_LATEST

All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make it easier to update everything

[PATCH for-8.1 v3 08/26] target/riscv/cpu.c: validate extensions before riscv_timer_init()

There is no need to init timers if we're not even sure that our extensions are valid. Execute riscv_cpu_validate_set_extensions() before riscv_timer_init(). Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git

[PATCH for-8.1 v3 10/26] target/riscv/cpu.c: avoid set_misa() in validate_set_extensions()

set_misa() will be tuned up to do more than it's already doing and it will be redundant to what riscv_cpu_validate_set_extensions() does. Note that we don't ever change env->misa_mlx in this function, so set_misa() can be replaced by just assigning env->misa_ext and env->misa_ext_mask to 'ext'.

[PATCH for-8.1 v3 03/26] target/riscv/cpu.c: remove set_priv_version()

The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza --- target/riscv/cpu.c | 30 +- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index

[PATCH for 8.0] qemu/osdep: Switch position of "extern" and "G_NORETURN"

Fixes the Windows build under msys2 using GCC 12 which fails with the following error: [184/579] Compiling C++ object qga/vss-win32/qga-vss.dll.p/install.cpp.obj FAILED: qga/vss-win32/qga-vss.dll.p/install.cpp.obj "c++" "-m64" "-mcx16" "-Iqga/vss-win32/qga-vss.dll.p" "-Iqga/vss-win32"

Should I record QEMU developers fortnightly call?

Hi I got asked several times if we have a record of previous QEMU calls. I think that we don't discuss anything that prevent us for recording the calls. But they have never been recorded in the past. Could we discuss if should record them and make the recordings available, or not? Is there

KVM call for agenda for 2023-03-21

Hi NOTE, NOTE, NOTE Remember that we are back in that crazy part of the year when daylight saving applies. Call is done on US timezone. If you are anything else, just doublecheck that it is working for you properly. NOTE, NOTE, NOTE Topics in the backburner: - single qemu binary

Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.

Hi Alex , Cédric, we have tried this *option:-serial *pty* -serial *pty* -serial *pty *-serial *pty *-serial *pty to check the serial output on screen. Here we are providing 2 scenarios without and with the changes suggested by @Cédric Le Goater . In first we are able to get /dev/ttyS4 serial

Re: [PATCH v8] audio/pwaudio.c: Add Pipewire audio backend for QEMU

Hi Dorinda, This commit adds a new audiodev backend to allow QEMU to use Pipewire as both an audio sink and source. This backend is available on most systems Add Pipewire entry points for QEMU Pipewire audio backend Add wrappers for QEMU Pipewire audio backend in qpw_pcm_ops() qpw_write

[PATCH for-8.0] Revert "ui: set cursor position upon listener registration"

Commit 6effaa16ac98 ("ui: set cursor position upon listener registration") causes the mouse cursor to be placed into the lower left corner when QEMU starts. This could be reproduced with just by running `qemu-system-x86_64`. This reverts commit 6effaa16ac9846e7d6197ee54a0551fba61aecd7.

Re: [PATCH] doc: do not recommend -blockdev

Michael Tokarev writes: > Currently, documentation recommends to use -blockdev instead of -drive. > This is quite a bit misleading, because -blockdev is "too" low-level, > requires good knowlege of how to construct block device stack, esp. > in context of various qcow2 layers, and requires too

Re: [PATCH 4/4] iotests/iov-padding: New test

On Fri, Mar 17, 2023 at 06:50:19PM +0100, Hanna Czenczek wrote: > Test that even vectored IO requests with 1024 vector elements that are > not aligned to the device's request alignment will succeed. > > Signed-off-by: Hanna Czenczek > --- > + > +# Four combinations: > +# - Offset 4096, length

Re: [PATCH 3/4] util/iov: Remove qemu_iovec_init_extended()

On Fri, Mar 17, 2023 at 06:50:18PM +0100, Hanna Czenczek wrote: > bdrv_pad_request() was the main user of qemu_iovec_init_extended(). > HEAD^ has removed that use, so we can remove qemu_iovec_init_extended() > now. > > The only remaining user is qemu_iovec_init_slice(), which can easily > inline

Re: [PATCH 2/4] block: Split padded I/O vectors exceeding IOV_MAX

On Fri, Mar 17, 2023 at 06:50:17PM +0100, Hanna Czenczek wrote: > When processing vectored guest requests that are not aligned to the > storage request alignment, we pad them by adding head and/or tail > buffers for a read-modify-write cycle. > > > To do this, the use of

Re: [PATCH 1/4] util/iov: Make qiov_slice() public

On Fri, Mar 17, 2023 at 06:50:16PM +0100, Hanna Czenczek wrote: > We want to inline qemu_iovec_init_extended() in block/io.c for padding > requests, and having access to qiov_slice() is useful for this. > > (We will need to count the number of I/O vector elements of a slice > there, and then

[RFC PATCH] metadata: add .git-blame-ignore-revs

Someone mentioned this on IRC so I thought I would try it out with a few commits that are pure code style fixes. Signed-off-by: Alex Bennée --- .git-blame-ignore-revs | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 .git-blame-ignore-revs diff --git

[PULL 05/31] gitlab: update centos-8-stream job

A couple of clean-ups here: - inherit from the custom runners job for artefacts - call check-avocado directly - add some comments to the top about setup Signed-off-by: Alex Bennée Reviewed-by: Thomas Huth Message-Id: <20230315174331.2959-6-alex.ben...@linaro.org> diff --git

[PULL 00/31] various fixes (testing, plugins, gitdm)

The following changes since commit 74c581b6452394e591f13beba9fea2ec0688e2f5: Merge tag 'trivial-branch-for-8.0-pull-request' of https://gitlab.com/laurent_vivier/qemu into staging (2023-03-17 14:22:01 +) are available in the Git repository at: https://gitlab.com/stsquad/qemu.git

[PULL 01/31] tests/avocado: update AArch64 tests to Alpine 3.17.2

From: Marcin Juszkiewicz To test Alpine boot on SBSA-Ref target we need Alpine Linux 'standard' image as 'virt' one lacks kernel modules. So to minimalize Avocado cache I move test to 'standard' image. Signed-off-by: Marcin Juszkiewicz Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Alex

[PULL 08/31] tests/avocado: don't use tags to define drive

We are abusing the avocado tags which are intended to provide test selection metadata to provide parameters to our test. This works OK up until the point you need to have ,'s in the field as this is the tag separator character which is the case for a number of the drive parameters. Fix this by

[PULL 07/31] tests/tcg: add some help output for running individual tests

So you can do: cd tests/tcg/aarch64-linux-user make -f ../Makefile.target help To see the list of tests. You can then run each one individually. Signed-off-by: Alex Bennée Acked-by: Richard Henderson Reviewed-by: Thomas Huth Message-Id: <20230315174331.2959-8-alex.ben...@linaro.org>

[PULL 04/31] scripts/ci: update gitlab-runner playbook to handle CentOS

This was broken when we moved to using the pre-built packages as we didn't take care to ensure we used RPMs where required. NB: I could never get this to complete on my test setup but I suspect this was down to network connectivity and timeouts while downloading. Fixes: 69c4befba1 (scripts/ci:

[PULL 02/31] tests/docker: all add DOCKER_BUILDKIT to RUNC environment

It seems we also need to pass DOCKER_BUILDKIT as an argument to docker itself to get the full benefit of caching. Signed-off-by: Alex Bennée Suggested-by: Fabiano Rosas Tested-by: Richard Henderson Reviewed-by: Thomas Huth Message-Id: <20230315174331.2959-3-alex.ben...@linaro.org> diff --git

[PULL 10/31] tcg: Drop plugin_gen_disable_mem_helpers from tcg_gen_exit_tb

From: Richard Henderson Now that we call qemu_plugin_disable_mem_helpers in cpu_tb_exec, we don't need to do this in generated code as well. Signed-off-by: Richard Henderson Message-Id: <20230310195252.210956-3-richard.hender...@linaro.org> Signed-off-by: Alex Bennée Message-Id:

[PULL 06/31] include/qemu: add documentation for memory callbacks

Some API documentation was missed, rectify that. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1497 Signed-off-by: Alex Bennée Reviewed-by: Richard Henderson Reviewed-by: Thomas Huth Message-Id: <20230315174331.2959-7-alex.ben...@linaro.org> diff --git a/include/qemu/qemu-plugin.h

[PULL 11/31] include/qemu/plugin: Remove QEMU_PLUGIN_ASSERT

From: Richard Henderson This macro is no longer used. Signed-off-by: Richard Henderson Message-Id: <20230310195252.210956-4-richard.hender...@linaro.org> Signed-off-by: Alex Bennée Message-Id: <20230315174331.2959-14-alex.ben...@linaro.org> diff --git a/include/qemu/plugin.h

[PULL 03/31] scripts/ci: add libslirp-devel to build-environment

Without libslip enabled we won't have user networking which means the KVM tests won't run. Reviewed-by: Thomas Huth Signed-off-by: Alex Bennée Message-Id: <20230315174331.2959-4-alex.ben...@linaro.org> diff --git a/scripts/ci/org.centos/stream/8/build-environment.yml

[PULL 09/31] tcg: Clear plugin_mem_cbs on TB exit

From: Richard Henderson Do this in cpu_tb_exec (normal exit) and cpu_loop_exit (exception), adjacent to where we reset can_do_io. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1381 Signed-off-by: Richard Henderson Message-Id: <20230310195252.210956-2-richard.hender...@linaro.org>

Re: Question about TCG liveness_pass_1

On 2023/3/17 22:02, Richard Henderson wrote: On 3/16/23 19:57, LIU Zhiwei wrote: Hi Richard, When I read the tcg code, I find a corner case which may be a bug in liveness_pass_1. I see all TEMP_TBs or global temps are set to TS_DEAD | TS_MEM when enter liveness_pass_1. Think about the 

[PATCH] doc: do not recommend -blockdev

Currently, documentation recommends to use -blockdev instead of -drive. This is quite a bit misleading, because -blockdev is "too" low-level, requires good knowlege of how to construct block device stack, esp. in context of various qcow2 layers, and requires too explicit configuration. More, quite

Re: [PATCH for 8.0 v3] memory: Prevent recursive memory access

On 2023/03/18 1:30, Peter Maydell wrote: On Thu, 16 Mar 2023 at 16:21, Akihiko Odaki wrote: A guest may request ask a memory-mapped device to perform DMA. If the address specified for DMA is the device performing DMA, it will create recursion. It is very unlikely that device implementations

Re: [PATCH for 8.0 v3] memory: Prevent recursive memory access

On 2023/03/18 1:25, Cédric Le Goater wrote: Hello, On 3/16/23 17:20, Akihiko Odaki wrote: A guest may request ask a memory-mapped device to perform DMA. If the address specified for DMA is the device performing DMA, it will create recursion. It is very unlikely that device implementations are