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@xxxxxxxxxxxxx>
> ---
> 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.
