On Thu, Apr 02, 2020 at 11:59:06AM +0200, Paolo Bonzini wrote:
> On 02/04/20 11:32, Stefan Hajnoczi wrote:
> > Paolo, I'm not sure how to interpret this case according to
> > docs/devel/atomics.txt. Maybe you can clarify.
> >
> > atomic_or() is sequentially consistent and I therefore expected it
On 02/04/20 11:32, Stefan Hajnoczi wrote:
> Paolo, I'm not sure how to interpret this case according to
> docs/devel/atomics.txt. Maybe you can clarify.
>
> atomic_or() is sequentially consistent and I therefore expected it to
> act as a barrier. Or does sequential consistency only cover the mem
On 2020/4/2 16:47, Paolo Bonzini wrote:
On 02/04/20 04:44, Ying Fang wrote:
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
On Thu, Apr 02, 2020 at 10:44:31AM +0800, Ying Fang wrote:
> 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
>
>
On 02/04/20 04:44, Ying Fang wrote:
> 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 ou
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 ma
