Qemu main thread is found to hang up in the mainloop when doing
image format convert on aarch64 platform and it is highly
reproduceable by executing test using:
qemu-img convert -f qcow2 -O qcow2 origin.qcow2 converted.qcow2
This mysterious hang can be explained by a race condition between
the main thread and an io worker thread. There can be a chance that
the last worker thread has called aio_bh_schedule_oneshot and it is
checking against notify_me to deliver a notfiy event. At the same
time, the main thread is calling aio_ctx_prepare however it first
calls qemu_timeout_ns_to_ms, thus the worker thread did not see
notify_me as true and did not send a notify event. The time line
can be shown in the following way:
Main Thread
------------------------------------------------
aio_ctx_prepare
atomic_or(&ctx->notify_me, 1);
/* out of order execution goes here */
*timeout = qemu_timeout_ns_to_ms(aio_compute_timeout(ctx));
Worker Thread
-----------------------------------------------
aio_bh_schedule_oneshot -> aio_bh_enqueue
aio_notify
smp_mb();
if (ctx->notify_me) { /* worker thread checks notify_me here */
event_notifier_set(&ctx->notifier);
atomic_mb_set(&ctx->notified, true);
}
Normal VM runtime is not affected by this hang since there is always some
timer timeout or subsequent io worker come and notify the main thead.
To fix this problem, a memory barrier is added to aio_ctx_prepare and
it is proved to have the hang fixed in our test.
This hang is not observed on the x86 platform however it can be easily
reproduced on the aarch64 platform, thus it is architecture related.
Not sure if this is revelant to Commit eabc977973103527bbb8fed69c91cfaa6691f8ab
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Reported-by: Euler Robot <euler.robot@huawei.com>
If a device is plugged in the pcie-root-port when VM kernel is
booting, the kernel may wrongly disable the device.
This bug was brought in by two patches of the linux kernel:
https://patchwork.kernel.org/patch/10575355/https://patchwork.kernel.org/patch/10766219/
VM runtime like kata uses this feature to boot microVM,
so we must fix it up. We hack into the pcie native hotplug
patch so that hotplug/unplug will work under this circumstance.
Signed-off-by: Ying Fang <fangying1@huawei.com>
block/iscsi: use MIN() between mx_sb_len and sb_len_wr
monitor: fix memory leak in monitor_fdset_dup_fd_find_remove
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Patch numbers are mismatched when QEMU is rebased from v4.0.0 to v4.0.1,
this patch is introduced to have it fixed.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Prepare for upgrading base package from 4.0.0 to 4.0.1.
Remove all the patches that have been contained in 4.0.1 base package.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
fno-inline option is need by hot-patch, but we didn't support
hot-patch in this version, remove it.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Without this serial, we can't start VM with more than 256 vcpus,
this is limited by kvm API, backport this serial to fix the bug.
With this patches, it can supports up to 512 vcpus.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
