Comment 2 for bug 1706296

On 25 July 2017 at 15:54, Alex Bennée <email address hidden> wrote:
>
> Thomas Huth <email address hidden> writes:
>
>> On 25.07.2017 11:30, Richard Jones wrote:
>>> ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())
>>> Aborted (core dumped)
>>>
>>> The stack trace in the failing thread is:
>>>
>>> Thread 4 (Thread 0x7fffb0418700 (LWP 21979)):
>>> #0 0x00007fffdd89b64b in raise () at /lib64/libc.so.6
>>> #1 0x00007fffdd89d450 in abort () at /lib64/libc.so.6
>>> #2 0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0
>>> #3 0x00007fffdff8c7ea in g_assertion_message_expr ()
>>> at /lib64/libglib-2.0.so.0
>>> #4 0x00005555557a7d00 in qemu_mutex_lock_iothread ()
>>> at /home/rjones/d/qemu/cpus.c:1580
>>> #5 0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678,
>>> iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4)
>>> at /home/rjones/d/qemu/accel/tcg/cputlb.c:795
>>> #6 0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400)
>>> at /home/rjones/d/qemu/softmmu_template.h:265
>>> #7 0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300
>>> #8 0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182
>>> #9 0x0000555555882610 in do_interrupt_protected (is_hw=<optimized
>>> out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>,
>>> intno=<optimized out>, env=0x555556751400) at
>>> /home/rjones/d/qemu/target/i386/seg_helper.c:758
>
> Erm, what is happening here? I think the seg_helper is writing a stack
> frame but for some reason to io memory, triggering the BQL. This just
> seems weird.

Even if this happens because the guest is going haywire,
if the guest can provoke it then we need to handle it
without asserting...

thanks
-- PMM