[PATCH 1/3] qemu: add option to process offloaded legacy blockjob event ealier

Peter Krempa pkrempa at redhat.com
Thu Oct 22 12:12:55 UTC 2020


On Tue, Oct 20, 2020 at 16:44:07 +0300, Nikolay Shirokovskiy wrote:
> Currently in qemuProcessHandleBlockJob we either offload blockjob event
> processing to the worker thread or notify another thread that waits for
> blockjob event and that thread processes the event. But sometimes after event
> is offloaded to the worker thread we need to process the event in a different
> thread.
> 
> To be able to to do it let's always set newstate/errmsg and then let whatever
> thread is first process it.
> 
> Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy at virtuozzo.com>
> ---
>  src/qemu/qemu_driver.c  | 17 ++++-------------
>  src/qemu/qemu_process.c | 20 ++++++++++++--------
>  2 files changed, 16 insertions(+), 21 deletions(-)
> 

[...]

> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 6422881..4d63e7d 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -953,13 +953,19 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon G_GNUC_UNUSED,
>      if (!(disk = qemuProcessFindDomainDiskByAliasOrQOM(vm, diskAlias, NULL)))
>          goto cleanup;
>  
> -    job = qemuBlockJobDiskGetJob(disk);
> +    if (!(job = qemuBlockJobDiskGetJob(disk))) {
> +        VIR_DEBUG("creating new block job object for '%s'", diskAlias);
> +        if (!(job = qemuBlockJobDiskNew(vm, disk, type, diskAlias)))

So this actually writes out the status XML. I'm not sure if that is a
good idea to do if we don't hold the domain job. The premise is that
threads holding the job lock might have partially modified it. 




More information about the libvir-list mailing list