+
imgfmt = os.environ.get('IMGFMT', 'raw')
imgproto = os.environ.get('IMGPROTO', 'file')
output_dir = os.environ.get('OUTPUT_DIR', '.')
@@ -614,6 +616,13 @@ def _post_shutdown(self) -> None:
super()._post_shutdown()
self.subprocess_check_valgrind(qemu_valgrind)
+
sys.exit(os.EX_USAGE)
+qemu_valgrind = []
+if os.environ.get('VALGRIND_QEMU') == "y" and \
+ os.environ.get('NO_VALGRIND') != "y":
+ valgrind_logfile = "--log-file=" + test_dir.strip()
a bit strange that you need to strip test_dir here.. Why?
Yep, it's unnecessary
On 28/05/2021 19:16, Vladimir Sementsov-Ogievskiy wrote:
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
docs/devel/testing.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Using the flag -p, allow the qemu binary to print to stdout.
Reviewed-by: Max Reitz
Signed-off-by: Emanuele Giuseppe Esposito
---
tests/qemu-iotests/check | 4 +++-
tests/qemu-iotests/iotests.py | 9 +
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
I'd merge it to previous patch. anyway:
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
docs/devel/testing.rst | 4
1 file changed, 4 insertions(+)
diff --git a/docs/devel/testing.rst
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Reviewed-by: Max Reitz
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
The priority will be given to gdb command line, meaning if the -gdb
parameter and -valgrind are given, gdb will be wrapped around
the qemu binary.
I'd prefer just return an error immediately if user specify both -gdb and
-valgrind
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
When using -valgrind on the script tests, it generates a log file
in $TEST_DIR that is either read (if valgrind finds problems) or
otherwise deleted. Provide the same exact behavior when using
-valgrind on the python tests.
Signed-off-by:
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
As with gdbserver, valgrind delays the test execution, so
the default QMP socket timeout timeout too soon.
First, "Timeout" class is a generic class for timeouts, not relying to sockets.
So, commit message lacks information about that we
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Currently, the check script only parses the option and sets the
VALGRIND_QEMU environmental variable to "y".
Add another local python variable that prepares the command line,
identical to the one provided in the test scripts.
Because the
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
docs/devel/testing.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
The only limitation here is that running a script with gdbserver
will make the test output mismatch with the expected
results, making the test fail.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Attaching gdbserver implies that the qmp socket
should wait indefinitely for an answer from QEMU.
Signed-off-by: Emanuele Giuseppe Esposito
---
tests/qemu-iotests/iotests.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Define -gdb flag and GDB_OPTIONS environment variable
to python tests to attach a gdbserver to each qemu instance.
This patch only adds and parses this flag, it does not yet add
the implementation for it.
if -gdb is not provided but
20.05.2021 17:21, Vladimir Sementsov-Ogievskiy wrote:
copy_range is not a default behavior since 6a30f663d4c0b3c, and it's
now available only though x-perf experimantal argument, so it's OK to
drop it.
Even when backup is used to copy disk to same filesystem, and
filesystem supports zero-copy
Currently we update s->use_copy_range and s->copy_size in
block_copy_do_copy().
It's not very good:
1. block_copy_do_copy() is intended to be a simple function, that wraps
bdrv_co_ functions for need of block copy. That's why we don't pass
BlockCopyTask into it. So, block_copy_do_copy() is bad
Don't report successful progress on failure, when call_state->ret is
set.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/block-copy.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/block/block-copy.c b/block/block-copy.c
index c2e5090412..f9e871b64f 100644
Hi all!
This is my suggestion how to refactor block-copy to avoid extra atomic
operations in
"[PATCH v2 0/7] block-copy: protect block-copy internal structures"
Vladimir Sementsov-Ogievskiy (2):
block-copy: fix block_copy_task_entry() progress update
block-copy: refactor copy_range handling
28.05.2021 14:01, Paolo Bonzini wrote:
On 28/05/21 12:24, Paolo Bonzini wrote:
It's still more complicated, because you need to add some kind of
method = s->method;
This would even have to be a separate, one-line critical section...
Hm, so, we should set .use_copy_range in task,
11.08.2020 12:54, Max Reitz wrote:
On 11.08.20 11:39, Peter Maydell wrote:
On Tue, 11 Aug 2020 at 10:35, Max Reitz wrote:
Hi,
There is a bug in the backup job that breaks backups from images whose
size is not aligned to the job's cluster size (i.e., qemu crashes
because of a failed
28.05.2021 14:01, Paolo Bonzini wrote:
On 28/05/21 12:24, Paolo Bonzini wrote:
It's still more complicated, because you need to add some kind of
method = s->method;
This would even have to be a separate, one-line critical section...
Or atomic operation.. What I don't like that all
On May 28 11:05, Niklas Cassel wrote:
From: Niklas Cassel
In the Zoned Namespace Command Set Specification, chapter
2.5.1 Managing resources
"The controller may transition zones in the ZSIO:Implicitly Opened state
to the ZSC:Closed state for resource management purposes."
The word may in
From: Niklas Cassel
In the Zoned Namespace Command Set Specification, chapter
2.5.1 Managing resources
"The controller may transition zones in the ZSIO:Implicitly Opened state
to the ZSC:Closed state for resource management purposes."
The word may in this sentence means that automatically
On 28/05/21 12:24, Paolo Bonzini wrote:
It's still more complicated, because you need to add some kind of
method = s->method;
This would even have to be a separate, one-line critical section...
Paolo
ret = block_copy_do_copy(..., method);
if (ret < 0 && method <=
On 18/05/21 12:07, Emanuele Giuseppe Esposito wrote:
+qemu_mutex_lock(_state->s->calls_lock);
QLIST_INSERT_HEAD(_state->s->calls, call_state, list);
+qemu_mutex_unlock(_state->s->calls_lock);
Let's just use tasks_lock here (maybe even rename it to just "lock").
Paolo
On 26/05/21 19:18, Vladimir Sementsov-Ogievskiy wrote:
It's actually the original idea of block_copy_do_copy() function: do
only simple copy, don't interact with the state. It's a kind of wrapper
on top of bdrv_co.
So, actually updating s->use_copy_range here was a bad idea.
It's still
On Wed, May 26, 2021 at 10:12:48AM +0100, Stefan Hajnoczi wrote:
> If the size of a VD_AGENT_CLIPBOARD_GRAB message is invalid we leak info
> when returning early.
>
> Thanks to Coverity for spotting this:
>
> *** CID 1453266: Resource leaks (RESOURCE_LEAK)
> /qemu/ui/vdagent.c: 465 in
28 matches
Mail list logo
