Re: [Qemu-devel] [TestDays] s390x emulation error

["Andreas Färber" <afaerber@suse.de>]

Am 12.11.2011 11:08, schrieb Andreas Färber:
> Am 10.11.2011 12:29, schrieb Andreas Färber:
>> Am 10.11.2011 11:32, schrieb Alexander Graf:
>>>
>>> On 10.11.2011, at 10:53, Andreas Färber <afaerber@suse.de> wrote:
>>>
>>>> Is there a known issue with running multiple instances of
>>>> qemu-system-s390x? I got a hang on openSUSE 12.1 RC2 x86_64 host:
>>>>
>>>> 0x00007f0de7f698d4 in __lll_lock_wait () from /lib64/libpthread.so.0
>>>> (gdb) bt
>>>> #0  0x00007f0de7f698d4 in __lll_lock_wait () from /lib64/libpthread.so.0
>>>> #1  0x00007f0de7f651c5 in _L_lock_883 () from /lib64/libpthread.so.0
>>>> #2  0x00007f0de7f6501a in pthread_mutex_lock () from /lib64/libpthread.so.0
>>>> #3  0x000000000048b4a9 in qemu_mutex_lock (mutex=<optimized out>)
>>>>    at /home/andreas/QEMU/qemu/qemu-thread-posix.c:54
>>>> #4  0x00000000004cd3df in qemu_mutex_lock_iothread ()
>>>>    at /home/andreas/QEMU/qemu/cpus.c:843
>>>> #5  0x0000000000467580 in main_loop_wait (nonblocking=<optimized out>)
>>>>    at /home/andreas/QEMU/qemu/main-loop.c:459
>>>> #6  0x0000000000408984 in main_loop () at /home/andreas/QEMU/qemu/vl.c:1481
>>>> #7  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
>>>>    at /home/andreas/QEMU/qemu/vl.c:3474
>>>>
>>>> Key presses didn't work, SDL window doesn't close, at 99.9% CPU.
>>>
>>> Huh? This is all generic code O_o. And no, it's not a known issue.
>>
>> Hm, reproducable by running
>>
>> $ s390x-softmmu/qemu-system-s390x
>>
>> (without arguments) on s390-next branch.
>>
>> I get compat_monitor0 console, but monitor or switching to real console
>> don't work and neither does closing. Same backtrace.
> 
> Same in my WIP qemu-system-rl78.
> 
> I found that the following main-loop change works around it for s390x
> and rl78 but breaks x86_64 SeaBIOS boot. [...]
> 
> diff --git a/main-loop.c b/main-loop.c
> index 60e9748..2ab5023 100644
> --- a/main-loop.c
> +++ b/main-loop.c
> @@ -460,7 +460,7 @@ int main_loop_wait(int nonblocking)
>      }
> 
>      glib_select_poll(&rfds, &wfds, &xfds, (ret < 0));
> -    qemu_iohandler_poll(&rfds, &wfds, &xfds, ret);
> +    qemu_iohandler_poll(&rfds, &wfds, &xfds, (ret < 0));
>  #ifdef CONFIG_SLIRP
>      slirp_select_poll(&rfds, &wfds, &xfds, (ret < 0));
>  #endif

For the record: While s390x and rl78 showed an identical backtrace in
gdb, the actual causes of the lockups turned out to be different:

For rl78, tlb_fill() was not yet fully/correctly implemented, with no TB
being generated for execution. We should probably error out rather than
going into an infinite loop then.

For s390x, the hang was workaroundable by memset()'ing not just the
virtio memory region but the whole of RAM. Still investigating.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg