From: Vladimir Sementsov-Ogievskiy
We are going to deprecate drive-backup, so use modern interface here.
In examples where target image creation is shown, show blockdev-add as
well. If target creation omitted, omit blockdev-add as well.
Reviewed-by: Kashyap Chamarthy
Signed-off-by: Vladimir Sem
See 03 commit message for details. 01-02 are preparation docs update.
v4: deprecate drive-backup transaction by squashing
[PATCH v4 5/5] block: Deprecate transaction type drive-backup
Message-Id: <20211025042405.3762351-6-arm...@redhat.com>
into PATCH 3
v3: wording fix-ups and
From: Vladimir Sementsov-Ogievskiy
We are going to deprecate drive-backup, so don't mention it here.
Moreover, blockdev-backup seems more correct in the context.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Signed-off-by: Markus Armbruster
---
docs/block-replication.txt
From: Vladimir Sementsov-Ogievskiy
Modern way is using blockdev-add + blockdev-backup, which provides a
lot more control on how target is opened.
As example of drive-backup problems consider the following:
User of drive-backup expects that target will be opened in the same
cache and aio mode as
On Wed, Nov 03, 2021 at 12:21:55PM -0400, Emanuele Giuseppe Esposito wrote:
> It seems that on_idle list is not properly initialized like
> the other notifiers.
>
> Signed-off-by: Emanuele Giuseppe Esposito
> ---
> job.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Stefan Hajnoczi
si
bdrv_cor_filter_drop() modifies the block graph. That means that other
parties can also modify the block graph before it returns. Therefore,
we cannot assume that the result of a graph traversal we did before
remains valid afterwards.
We should thus fetch `base` and `unfiltered_base` afterwards
Hi,
I’ve tried to investigate what causes the iotest 030 to fail. Here’s
what I found:
(1) stream_prepare() gets the base node by looking up the node below
above_base. It then invokes bdrv_cor_filter_drop(), before we
actually use the base node.
bdrv_cor_filter_drop() modifies the b
The children list is specific to BDS parents. We should not modify it
in the general children modification code, but let BDS parents deal with
it in their .attach() and .detach() methods.
This also has the advantage that a BdrvChild is removed from the
children list before its .bs pointer can bec
See the comment for why this is necessary.
Signed-off-by: Hanna Reitz
---
tests/qemu-iotests/030 | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 5fb65b4bef..567bf1da67 100755
--- a/tests/qemu-iotests/030
+++ b/
Now that bdrv_remove_empty_child() no longer removes the child from the
parent's children list but only checks that it is not in such a list, it
is only a wrapper around bdrv_child_free() that checks that the child is
empty and unused. That should apply to all children that we free, so
put those c
bdrv_replace_child_noperm() modifies BdrvChild.bs, and can potentially
set it to NULL. That is dangerous, because BDS parents generally assume
that their children's .bs pointer is never NULL. We therefore want to
let bdrv_replace_child_noperm() set the corresponding BdrvChild pointer
to NULL, too
bdrv_attach_child_common_abort() restores the parent's AioContext. To
do so, the child (which was supposed to be attached, but is now detached
again by this abort handler) is added to the ignore list for the
AioContext changing functions.
However, since we modify a BDS's children list in the Bdrv
In most of the block layer, especially when traversing down from other
BlockDriverStates, we assume that BdrvChild.bs can never be NULL. When
it becomes NULL, it is expected that the corresponding BdrvChild pointer
also becomes NULL and the BdrvChild object is freed.
Therefore, once bdrv_replace_
At the end of a reopen, we already call bdrv_refresh_limits(), which
should update bs->request_alignment according to the new file
descriptor. However, raw_probe_alignment() relies on s->needs_alignment
and just uses 1 if it isn't set. We neglected to update this field, so
starting with cache=write
Am 04.11.2021 um 11:38 hat Hanna Reitz geschrieben:
> (2A) bdrv_replace_child_noperm() should immediately set bs->file or
> bs->backing to NULL when it sets bs->{file,backing}->bs to NULL.
> It should also immediately remove any BdrvChild with .bs == NULL
> from the parent’s BDS.chil
On 04.11.21 12:31, Kevin Wolf wrote:
At the end of a reopen, we already call bdrv_refresh_limits(), which
should update bs->request_alignment according to the new file
descriptor. However, raw_probe_alignment() relies on s->needs_alignment
and just uses 1 if it isn't set. We neglected to update t
On 04.11.21 12:58, Kevin Wolf wrote:
Am 04.11.2021 um 11:38 hat Hanna Reitz geschrieben:
(2A) bdrv_replace_child_noperm() should immediately set bs->file or
bs->backing to NULL when it sets bs->{file,backing}->bs to NULL.
It should also immediately remove any BdrvChild with .bs == NU
On Tue, Nov 02, 2021 at 06:33:31PM +0100, Lukasz Maniak wrote:
> On Tue, Nov 02, 2021 at 03:33:15PM +0100, Klaus Jensen wrote:
> > On Oct 7 18:23, Lukasz Maniak wrote:
> > > This patch implements initial support for Single Root I/O Virtualization
> > > on an NVMe device.
> > >
> > > Essentially,
On Thu, Nov 04, 2021 at 12:31:09PM +0100, Kevin Wolf wrote:
At the end of a reopen, we already call bdrv_refresh_limits(), which
should update bs->request_alignment according to the new file
descriptor. However, raw_probe_alignment() relies on s->needs_alignment
and just uses 1 if it isn't set. W
On Mittwoch, 3. November 2021 12:33:33 CET Stefan Hajnoczi wrote:
> On Mon, Nov 01, 2021 at 09:29:26PM +0100, Christian Schoenebeck wrote:
> > On Donnerstag, 28. Oktober 2021 11:00:48 CET Stefan Hajnoczi wrote:
> > > On Mon, Oct 25, 2021 at 05:03:25PM +0200, Christian Schoenebeck wrote:
> > > > On
Am 04.11.2021 um 15:20 hat Stefano Garzarella geschrieben:
> On Thu, Nov 04, 2021 at 12:31:09PM +0100, Kevin Wolf wrote:
> > At the end of a reopen, we already call bdrv_refresh_limits(), which
> > should update bs->request_alignment according to the new file
> > descriptor. However, raw_probe_alig
These functions assume that the job lock is held by the
caller, to avoid TOC/TOU conditions.
Introduce also additional helpers that define _locked
functions (useful when the job_mutex is globally applied).
Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*.
Signed-off-by:
In this series, we want to remove the AioContext lock and instead
use the already existent job_mutex to protect the job structures
and list. This is part of the work to get rid of AioContext lock
usage in favour of smaller granularity locks.
In order to simplify reviewer's job, job lock/unlock fun
Categorize the fields in struct Job to understand which ones
need to be protected by the job mutex and which don't.
Signed-off-by: Emanuele Giuseppe Esposito
---
include/qemu/job.h | 57 +++---
1 file changed, 34 insertions(+), 23 deletions(-)
diff --git
job mutex will be used to protect the job struct elements and list,
replacing AioContext locks.
Right now use a shared lock for all jobs, in order to keep things
simple. Once the AioContext lock is gone, we can introduce per-job
locks.
To simplify the switch from aiocontext to job lock, introduce
All these functions assume that the lock is not held, and acquire
it internally.
These functions will be useful when job_lock is globally applied,
as they will allow callers to access the job struct fields
without worrying about the job lock.
Update also the comments in blockjob.c (and move them
job_event_* functions can all be static, as they are not used
outside job.c.
Signed-off-by: Emanuele Giuseppe Esposito
---
include/qemu/job.h | 6 --
job.c | 12 ++--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/qemu/job.h b/include/qemu/job.h
Both blockdev.c and job-qmp.c have TOC/TOU conditions, because
they first search for the job and then perform an action on it.
Therefore, we need to do the search + action under the same
job mutex critical section.
Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*.
Signed
Same as AIO_WAIT_WHILE macro, but if we are in the Main loop
do not release and then acquire ctx_ 's aiocontext.
Once all Aiocontext locks go away, this macro will replace
AIO_WAIT_WHILE.
Signed-off-by: Emanuele Giuseppe Esposito
---
include/block/aio-wait.h | 15 +++
1 file changed
Once job lock is used and aiocontext is removed, mirror has
to perform job operations under the same critical section,
using the helpers prepared in previous commit.
Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*.
Signed-off-by: Emanuele Giuseppe Esposito
---
block/m
In preparation to the job_lock/unlock patch, remove these
aiocontext locks.
The main reason these two locks are removed here is because
they are inside a loop iterating on the jobs list. Once the
job_lock is added, it will have to protect the whole loop,
wrapping also the aiocontext acquire/release
Not sure what the atomic here was supposed to do, since job.busy
is protected by the job lock. Since the whole function will
be called under job_mutex, just remove the atomic.
Signed-off-by: Emanuele Giuseppe Esposito
---
blockjob.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
dif
Introduce the job locking mechanism through the whole job API,
following the comments and requirements of job-monitor (assume
lock is held) and job-driver (lock is not held).
job_{lock/unlock} is independent from _job_{lock/unlock}.
Note: at this stage, job_{lock/unlock} and job lock guard macros
Instead of having the lock in job_tnx_apply, move it inside
in the callback. This will be helpful for next commits, when
we introduce job_lock/unlock pairs.
job_transition_to_pending() and job_needs_finalize() do not
need to be protected by the aiocontext lock.
No functional change intended.
Sig
Change the job_{lock/unlock} and macros to use job_mutex.
Now that they are not nop anymore, remove the aiocontext
to avoid deadlocks.
Therefore:
- when possible, remove completely the aiocontext lock/unlock pair
- if it is used by some other functions too, reduce the locking
section as much as p
Add missing job synchronization in the unit tests, with
both explicit locks and helpers.
Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*.
Signed-off-by: Emanuele Giuseppe Esposito
---
tests/unit/test-bdrv-drain.c | 40 +++---
tests/unit/test-block-
Jonah Palmer writes:
> From: Laurent Vivier
>
> This new command lists all the instances of VirtIODevice with
> their QOM paths and virtio type/name.
>
> Signed-off-by: Jonah Palmer
> ---
> hw/virtio/meson.build | 2 ++
> hw/virtio/virtio-stub.c| 14 ++
> hw/virtio/virtio.c
job-common.h contains all struct and common function that currently
are in job.h and will be shared by job-monitor and job-driver in
the next commits.
Also move job_type() and job_type_str() there, as they are
common helper functions.
No functional change intended.
Signed-off-by: Emanuele Giusep
job-monitor.h contains all functions of job.h that are used by the
monitor and essentially all functions that do not define a
JobDriver/Blockdriver.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
include/qemu/job-monitor.h | 282
In this series, we split the job API in two headers:
job-driver.h and job-monitor.h.
As explained in job.c, job-monitor are the functions mainly used
by the monitor, and require consistency between the search of
a specific job (job_get) and the actual operation/action on it
(e.g. job_user_cancel).
job-driver.h contains all functions of job.h that are used by
the drivers (JobDriver, BlockJobDriver).
These functions are unaware of the job_mutex,
so they all take and release the lock internally.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
include/qemu/job-d
Jonah Palmer writes:
> From: Laurent Vivier
>
> This new command shows the status of a VirtIODevice, including
> its corresponding vhost device status (if active).
>
> Next patch will improve output by decoding feature bits, including
> vhost device's feature bits (backend, protocol, acked, and
On Wed, Nov 03, 2021 at 01:07:31PM +0100, Klaus Jensen wrote:
> On Oct 7 18:24, Lukasz Maniak wrote:
> > From: Łukasz Gieryk
> >
> > With two new properties (sriov_max_vi_per_vf, sriov_max_vq_per_vf) one
> > can configure the maximum number of virtual queues and interrupts
> > assignable to a si
On Wed, Nov 03, 2021 at 02:29:12PM +0100, Vladimir Sementsov-Ogievskiy wrote:
> Modern way is using blockdev-add + blockdev-backup, which provides a
> lot more control on how target is opened.
>
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Kashyap Chamarthy
> ---
> docs/abou
44 matches
Mail list logo
