18.03.2023 15:32, Alex Bennée пишет:
..
Could we expand the images section:
https://qemu.readthedocs.io/en/latest/system/images.html
to give a better overview of when you should use -device/-blockdev vs -drive?
Probably. It's not really about image formats but this info should be
somewher
+ 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: qga/vss-
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 100
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
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 a
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 ++---
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
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: Da
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 CP
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 ++
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 t
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.
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 changed
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. Th
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 alread
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 th
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. Si
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
---
target/riscv/c
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, sin
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
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
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 r
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.
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 altern
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 futur
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 at
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
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'.
S
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 2752efe1eb..18032
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"
"-I..
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 any
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
Philippe?
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 por
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 functio
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.
Signed-off
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
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 10
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 t
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 qemu_iovec_init_extended
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 later
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 a/.git-blame-ign
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 a/.gitlab-ci.
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 tags/pu
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 B
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 maki
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>
diff
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: up
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
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: <2023031517433
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 b/inc
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 b/include/qemu/pl
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
b/scripts/ci/org.centos/st
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>
Sign
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 se
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
55 matches
Mail list logo