does make check now require TCG? Or is it a parallelism issue?

does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

on master, a build without tcg like:

exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"

make -j120 check
Generating qemu-version.h with a meson_exe.py custom command
make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
make: *** Waiting for unfinished jobs....

qemu-system-aarch64 is required for check-block now?

If I run without -j:

Running test qtest-i386: qmp-cmd-test
Broken pipe
../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
make: *** [Makefile.mtest:1074: run-test-151] Error 1

Ciao,

Claudio

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 08/10/20 16:48, Claudio Fontana wrote:
> on master, a build without tcg like:
> 
> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
> 
> make -j120 check
> Generating qemu-version.h with a meson_exe.py custom command
> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
> make: *** Waiting for unfinished jobs....
> 
> qemu-system-aarch64 is required for check-block now?

No, it's not, it's an unnecessary dependency.  This will fix it:

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 5aca98e60c..1ca70d88ce 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
 check: check-block
 check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
 		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
-		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
+		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
 	@$<
 endif
 


> If I run without -j:
> 
> Running test qtest-i386: qmp-cmd-test
> Broken pipe
> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
> make: *** [Makefile.mtest:1074: run-test-151] Error 1

This one is different and I've never seen it.

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 5:02 PM, Paolo Bonzini wrote:
> On 08/10/20 16:48, Claudio Fontana wrote:
>> on master, a build without tcg like:
>>
>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>
>> make -j120 check
>> Generating qemu-version.h with a meson_exe.py custom command
>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>> make: *** Waiting for unfinished jobs....
>>
>> qemu-system-aarch64 is required for check-block now?
> 
> No, it's not, it's an unnecessary dependency.  This will fix it:
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 5aca98e60c..1ca70d88ce 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>  check: check-block
>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>  	@$<
>  endif
>  
> 
> 

thanks this works!

>> If I run without -j:
>>
>> Running test qtest-i386: qmp-cmd-test
>> Broken pipe
>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
> 
> This one is different and I've never seen it.

This one seems an additional, non-tcg build only error, will update when I have more details.

> 
> Paolo
> 

Ciao,

Claudio

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 5:34 PM, Claudio Fontana wrote:
> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>> On 08/10/20 16:48, Claudio Fontana wrote:
>>> on master, a build without tcg like:
>>>
>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>
>>> make -j120 check
>>> Generating qemu-version.h with a meson_exe.py custom command
>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>> make: *** Waiting for unfinished jobs....
>>>
>>> qemu-system-aarch64 is required for check-block now?
>>
>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>
>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>> index 5aca98e60c..1ca70d88ce 100644
>> --- a/tests/Makefile.include
>> +++ b/tests/Makefile.include
>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>  check: check-block
>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>  	@$<
>>  endif
>>  
>>
>>
> 
> thanks this works!
> 
>>> If I run without -j:
>>>
>>> Running test qtest-i386: qmp-cmd-test
>>> Broken pipe
>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>
>> This one is different and I've never seen it.
> 
> This one seems an additional, non-tcg build only error, will update when I have more details.
> 
>>
>> Paolo
>>
> 
> Ciao,
> 
> Claudio
> 

Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..

(gdb) bt
#0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
#1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
#2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
#3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
#4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
#5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
    at qapi/qapi-commands-replay.c:55
#6  0x000056295aae88a3 in qmp_dispatch
    (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
#7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
#8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
#9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
#10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
#11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
    at ../util/async.c:306
#12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
#14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
#15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
#16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
#17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 08/10/20 18:25, Claudio Fontana wrote:
> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>> on master, a build without tcg like:
>>>>
>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>
>>>> make -j120 check
>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>> make: *** Waiting for unfinished jobs....
>>>>
>>>> qemu-system-aarch64 is required for check-block now?
>>>
>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>
>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>> index 5aca98e60c..1ca70d88ce 100644
>>> --- a/tests/Makefile.include
>>> +++ b/tests/Makefile.include
>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>  check: check-block
>>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>  	@$<
>>>  endif
>>>  
>>>
>>>
>>
>> thanks this works!
>>
>>>> If I run without -j:
>>>>
>>>> Running test qtest-i386: qmp-cmd-test
>>>> Broken pipe
>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>
>>> This one is different and I've never seen it.
>>
>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>
>>>
>>> Paolo
>>>
>>
>> Ciao,
>>
>> Claudio
>>
> 
> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
> 
> (gdb) bt
> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>     at qapi/qapi-commands-replay.c:55
> #6  0x000056295aae88a3 in qmp_dispatch
>     (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>     at ../util/async.c:306
> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
> 

Ah, query-replay probably should return an error if !tcg_enabled().

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 6:31 PM, Paolo Bonzini wrote:
> On 08/10/20 18:25, Claudio Fontana wrote:
>> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>>> on master, a build without tcg like:
>>>>>
>>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>>
>>>>> make -j120 check
>>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>>> make: *** Waiting for unfinished jobs....
>>>>>
>>>>> qemu-system-aarch64 is required for check-block now?
>>>>
>>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>>
>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>> index 5aca98e60c..1ca70d88ce 100644
>>>> --- a/tests/Makefile.include
>>>> +++ b/tests/Makefile.include
>>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>>  check: check-block
>>>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>>  	@$<
>>>>  endif
>>>>  
>>>>
>>>>
>>>
>>> thanks this works!
>>>
>>>>> If I run without -j:
>>>>>
>>>>> Running test qtest-i386: qmp-cmd-test
>>>>> Broken pipe
>>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>>
>>>> This one is different and I've never seen it.
>>>
>>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>>
>>>>
>>>> Paolo
>>>>
>>>
>>> Ciao,
>>>
>>> Claudio
>>>
>>
>> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
>>
>> (gdb) bt
>> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
>> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
>> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
>> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
>> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
>> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>>     at qapi/qapi-commands-replay.c:55
>> #6  0x000056295aae88a3 in qmp_dispatch
>>     (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
>> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
>> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
>> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
>> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
>> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>>     at ../util/async.c:306
>> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
>> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
>> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
>> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
>> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
>> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
>>
> 
> Ah, query-replay probably should return an error if !tcg_enabled().
> 
> Paolo
> 

aha, and we might even compile away (almost) the whole replay/ if not under tcg, and just put the necessary qmp stuff in stubs/ ... ?

Ciao,

C

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 6:35 PM, Claudio Fontana wrote:
> On 10/8/20 6:31 PM, Paolo Bonzini wrote:
>> On 08/10/20 18:25, Claudio Fontana wrote:
>>> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>>>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>>>> on master, a build without tcg like:
>>>>>>
>>>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>>>
>>>>>> make -j120 check
>>>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>>>> make: *** Waiting for unfinished jobs....
>>>>>>
>>>>>> qemu-system-aarch64 is required for check-block now?
>>>>>
>>>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>>>
>>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>>> index 5aca98e60c..1ca70d88ce 100644
>>>>> --- a/tests/Makefile.include
>>>>> +++ b/tests/Makefile.include
>>>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>>>  check: check-block
>>>>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>>>  	@$<
>>>>>  endif
>>>>>  
>>>>>
>>>>>
>>>>
>>>> thanks this works!
>>>>
>>>>>> If I run without -j:
>>>>>>
>>>>>> Running test qtest-i386: qmp-cmd-test
>>>>>> Broken pipe
>>>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>>>
>>>>> This one is different and I've never seen it.
>>>>
>>>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>>>
>>>>>
>>>>> Paolo
>>>>>
>>>>
>>>> Ciao,
>>>>
>>>> Claudio
>>>>
>>>
>>> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
>>>
>>> (gdb) bt
>>> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
>>> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
>>> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
>>> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
>>> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
>>> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>>>     at qapi/qapi-commands-replay.c:55
>>> #6  0x000056295aae88a3 in qmp_dispatch
>>>     (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
>>> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
>>> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
>>> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
>>> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
>>> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>>>     at ../util/async.c:306
>>> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
>>> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
>>> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
>>> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
>>> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
>>> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
>>>
>>
>> Ah, query-replay probably should return an error if !tcg_enabled().
>>
>> Paolo
>>
> 
> aha, and we might even compile away (almost) the whole replay/ if not under tcg, and just put the necessary qmp stuff in stubs/ ... ?
> 
> Ciao,
> 
> C
> 

Oh I see there has been quite a lot of new replay code grafted around the codebase.

I guess the commit breaking the fun for me was

e3b09ad2b6e9b23ebc7c2ba133e8a22e53dec301

commit e3b09ad2b6e9b23ebc7c2ba133e8a22e53dec301
Author: Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>
Date:   Sat Oct 3 20:13:20 2020 +0300

    replay: introduce info hmp/qmp command
    
    This patch introduces 'info replay' monitor command and
    corresponding qmp request.
    These commands request the current record/replay mode, replay log file
    name, and the instruction count (number of recorded/replayed
    instructions).  The instruction count can be used with the
    replay_seek/replay_break commands added in the next two patches.
    
    Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
    Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Acked-by: Markus Armbruster <armbru@redhat.com>
    Message-Id: <160174520026.12451.13112161947433306561.stgit@pasha-ThinkPad-X280>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Re: does make check now require TCG? Or is it a parallelism issue?

[Philippe Mathieu-Daudé]

On 10/8/20 6:35 PM, Claudio Fontana wrote:
> On 10/8/20 6:31 PM, Paolo Bonzini wrote:
>> On 08/10/20 18:25, Claudio Fontana wrote:
>>> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>>>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>>>> on master, a build without tcg like:
>>>>>>
>>>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>>>
>>>>>> make -j120 check
>>>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>>>> make: *** Waiting for unfinished jobs....
>>>>>>
>>>>>> qemu-system-aarch64 is required for check-block now?
>>>>>
>>>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>>>
>>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>>> index 5aca98e60c..1ca70d88ce 100644
>>>>> --- a/tests/Makefile.include
>>>>> +++ b/tests/Makefile.include
>>>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>>>   check: check-block
>>>>>   check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>>>   		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>>>   	@$<
>>>>>   endif
>>>>>   
>>>>>
>>>>>
>>>>
>>>> thanks this works!
>>>>
>>>>>> If I run without -j:
>>>>>>
>>>>>> Running test qtest-i386: qmp-cmd-test
>>>>>> Broken pipe
>>>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>>>
>>>>> This one is different and I've never seen it.
>>>>
>>>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>>>
>>>>>
>>>>> Paolo
>>>>>
>>>>
>>>> Ciao,
>>>>
>>>> Claudio
>>>>
>>>
>>> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
>>>
>>> (gdb) bt
>>> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
>>> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
>>> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
>>> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
>>> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
>>> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>>>      at qapi/qapi-commands-replay.c:55
>>> #6  0x000056295aae88a3 in qmp_dispatch
>>>      (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
>>> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
>>> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
>>> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
>>> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
>>> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>>>      at ../util/async.c:306
>>> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
>>> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
>>> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
>>> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
>>> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
>>> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
>>>
>>
>> Ah, query-replay probably should return an error if !tcg_enabled().
>>
>> Paolo
>>
> 
> aha, and we might even compile away (almost) the whole replay/ if not under tcg, and just put the necessary qmp stuff in stubs/ ... ?

Soft accelerator are TCG and QTest. Replay only works with soft
accelerator. Should replay work with QTest? Is this useful?
(if there are no instructions, what can we replay, IRQs?)

If replay is only usable with TCG, can we merge it into it?
It seems quite accel-related.

Noob questions as I don't understand well the coverage of replay.

Regards,

Phil.

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/9/20 11:23 AM, Philippe Mathieu-Daudé wrote:
> On 10/8/20 6:35 PM, Claudio Fontana wrote:
>> On 10/8/20 6:31 PM, Paolo Bonzini wrote:
>>> On 08/10/20 18:25, Claudio Fontana wrote:
>>>> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>>>>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>>>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>>>>> on master, a build without tcg like:
>>>>>>>
>>>>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>>>>
>>>>>>> make -j120 check
>>>>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>>>>> make: *** Waiting for unfinished jobs....
>>>>>>>
>>>>>>> qemu-system-aarch64 is required for check-block now?
>>>>>>
>>>>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>>>>
>>>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>>>> index 5aca98e60c..1ca70d88ce 100644
>>>>>> --- a/tests/Makefile.include
>>>>>> +++ b/tests/Makefile.include
>>>>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>>>>   check: check-block
>>>>>>   check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>>>>   		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>>>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>>>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>>>>   	@$<
>>>>>>   endif
>>>>>>   
>>>>>>
>>>>>>
>>>>>
>>>>> thanks this works!
>>>>>
>>>>>>> If I run without -j:
>>>>>>>
>>>>>>> Running test qtest-i386: qmp-cmd-test
>>>>>>> Broken pipe
>>>>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>>>>
>>>>>> This one is different and I've never seen it.
>>>>>
>>>>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>>>>
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>> Claudio
>>>>>
>>>>
>>>> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
>>>>
>>>> (gdb) bt
>>>> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
>>>> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
>>>> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
>>>> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
>>>> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
>>>> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>>>>      at qapi/qapi-commands-replay.c:55
>>>> #6  0x000056295aae88a3 in qmp_dispatch
>>>>      (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
>>>> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
>>>> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
>>>> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
>>>> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
>>>> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>>>>      at ../util/async.c:306
>>>> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
>>>> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
>>>> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
>>>> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
>>>> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
>>>> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
>>>>
>>>
>>> Ah, query-replay probably should return an error if !tcg_enabled().
>>>
>>> Paolo
>>>
>>
>> aha, and we might even compile away (almost) the whole replay/ if not under tcg, and just put the necessary qmp stuff in stubs/ ... ?
> 
> Soft accelerator are TCG and QTest. Replay only works with soft
> accelerator. Should replay work with QTest? Is this useful?
> (if there are no instructions, what can we replay, IRQs?)
> 
> If replay is only usable with TCG, can we merge it into it?
> It seems quite accel-related.
> 
> Noob questions as I don't understand well the coverage of replay.
> 
> Regards,
> 
> Phil.
> 

Hello Philippe,

I have the same questions, and I am trying to understand what is the best way forward.
As a background, ultimately I would like all components of qemu to be highly modular and we are very much on this path I think.

Accelerator-wise, as I mentioned previously I am trying to reach the point where we can say CONFIG_TCG=m,
(and CONFIG_KVM=m, etc...) and be able to install only a simple qemu base,
and have everything else as optional modules, including per-target accelerator modules.

Currently (in master) replay/ is built unconditionally, but I have already a rough patch to make it conditional
on CONFIG_TCG with a lot of stuff added to stub/ .

However, I'd like it even better if it is part of accel/ in the sense that it would be easier then to limit the scope of the overall tcg dynamic module,
which is already quite spread out in the code

(fpu/, tcg/, target/$(TARGET_BASE_ARCH)/, accel/tcg/ , replay/ at least).

Maybe Pavel has some clarification for us on the role and relationships of the replay module with the other components?
Where do we think is the right balance in general in sorting out TCG components?

Thanks,

Claudio

Re: does make check now require TCG? Or is it a parallelism issue?

[Pavel Dovgalyuk]

On 09.10.2020 12:40, Claudio Fontana wrote:
> On 10/9/20 11:23 AM, Philippe Mathieu-Daudé wrote:
>> On 10/8/20 6:35 PM, Claudio Fontana wrote:
>>> On 10/8/20 6:31 PM, Paolo Bonzini wrote:
>>>> On 08/10/20 18:25, Claudio Fontana wrote:
>>>>> On 10/8/20 5:34 PM, Claudio Fontana wrote:
>>>>>> On 10/8/20 5:02 PM, Paolo Bonzini wrote:
>>>>>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>>>>>> on master, a build without tcg like:
>>>>>>>>
>>>>>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>>>>>
>>>>>>>> make -j120 check
>>>>>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>>>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>>>>>> make: *** Waiting for unfinished jobs....
>>>>>>>>
>>>>>>>> qemu-system-aarch64 is required for check-block now?
>>>>>>>
>>>>>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>>>>>
>>>>>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>>>>>> index 5aca98e60c..1ca70d88ce 100644
>>>>>>> --- a/tests/Makefile.include
>>>>>>> +++ b/tests/Makefile.include
>>>>>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>>>>>    check: check-block
>>>>>>>    check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>>>>>    		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>>>>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>>>>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>>>>>>    	@$<
>>>>>>>    endif
>>>>>>>    
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> thanks this works!
>>>>>>
>>>>>>>> If I run without -j:
>>>>>>>>
>>>>>>>> Running test qtest-i386: qmp-cmd-test
>>>>>>>> Broken pipe
>>>>>>>> ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
>>>>>>>> ERROR qtest-i386: qmp-cmd-test - too few tests run (expected 53, got 45)
>>>>>>>> make: *** [Makefile.mtest:1074: run-test-151] Error 1
>>>>>>>
>>>>>>> This one is different and I've never seen it.
>>>>>>
>>>>>> This one seems an additional, non-tcg build only error, will update when I have more details.
>>>>>>
>>>>>>>
>>>>>>> Paolo
>>>>>>>
>>>>>>
>>>>>> Ciao,
>>>>>>
>>>>>> Claudio
>>>>>>
>>>>>
>>>>> Seems to be some QMP calls to icount code from replay happening during the tests, which of course do not find any icount there..
>>>>>
>>>>> (gdb) bt
>>>>> #0  0x00007f2b4d115520 in raise () at /lib64/libc.so.6
>>>>> #1  0x00007f2b4d116b01 in abort () at /lib64/libc.so.6
>>>>> #2  0x000056295aaf5889 in icount_get_raw () at ../stubs/icount.c:20
>>>>> #3  0x000056295a7934a5 in replay_get_current_icount () at ../replay/replay.c:71
>>>>> #4  0x000056295a78719d in qmp_query_replay (errp=errp@entry=0x7ffe727a4538) at ../replay/replay-debugging.c:55
>>>>> #5  0x000056295aac0137 in qmp_marshal_query_replay (args=<optimized out>, ret=0x7ffe727a45a0, errp=0x7ffe727a4598)
>>>>>       at qapi/qapi-commands-replay.c:55
>>>>> #6  0x000056295aae88a3 in qmp_dispatch
>>>>>       (cmds=0x56295b3b5ce0 <qmp_commands>, request=request@entry=0x7f2b3c004db0, allow_oob=<optimized out>) at ../qapi/qmp-dispatch.c:155
>>>>> #7  0x000056295aa6ab7f in monitor_qmp_dispatch (mon=0x56295bee7f80, req=0x7f2b3c004db0) at ../monitor/qmp.c:145
>>>>> #8  0x000056295aa6b3ba in monitor_qmp_bh_dispatcher (data=<optimized out>) at ../monitor/qmp.c:234
>>>>> #9  0x000056295aaeb5b8 in aio_bh_poll (ctx=ctx@entry=0x56295bcd5130) at ../util/async.c:164
>>>>> #10 0x000056295aad76de in aio_dispatch (ctx=0x56295bcd5130) at ../util/aio-posix.c:380
>>>>> #11 0x000056295aaeb49e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
>>>>>       at ../util/async.c:306
>>>>> #12 0x00007f2b4e268f07 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
>>>>> #13 0x000056295aac96fa in glib_pollfds_poll () at ../util/main-loop.c:221
>>>>> #14 0x000056295aac96fa in os_host_main_loop_wait (timeout=-1) at ../util/main-loop.c:244
>>>>> #15 0x000056295aac96fa in main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:520
>>>>> #16 0x000056295a99083d in qemu_main_loop () at ../softmmu/vl.c:1677
>>>>> #17 0x000056295a71b17e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50
>>>>>
>>>>
>>>> Ah, query-replay probably should return an error if !tcg_enabled().
>>>>
>>>> Paolo
>>>>
>>>
>>> aha, and we might even compile away (almost) the whole replay/ if not under tcg, and just put the necessary qmp stuff in stubs/ ... ?
>>
>> Soft accelerator are TCG and QTest. Replay only works with soft
>> accelerator. Should replay work with QTest? Is this useful?
>> (if there are no instructions, what can we replay, IRQs?)
>>
>> If replay is only usable with TCG, can we merge it into it?
>> It seems quite accel-related.
>>
>> Noob questions as I don't understand well the coverage of replay.
>>
>> Regards,
>>
>> Phil.
>>
> 
> Hello Philippe,
> 
> I have the same questions, and I am trying to understand what is the best way forward.
> As a background, ultimately I would like all components of qemu to be highly modular and we are very much on this path I think.
> 
> Accelerator-wise, as I mentioned previously I am trying to reach the point where we can say CONFIG_TCG=m,
> (and CONFIG_KVM=m, etc...) and be able to install only a simple qemu base,
> and have everything else as optional modules, including per-target accelerator modules.
> 
> Currently (in master) replay/ is built unconditionally, but I have already a rough patch to make it conditional
> on CONFIG_TCG with a lot of stuff added to stub/ .
> 
> However, I'd like it even better if it is part of accel/ in the sense that it would be easier then to limit the scope of the overall tcg dynamic module,
> which is already quite spread out in the code
> 
> (fpu/, tcg/, target/$(TARGET_BASE_ARCH)/, accel/tcg/ , replay/ at least).
> 
> Maybe Pavel has some clarification for us on the role and relationships of the replay module with the other components?
> Where do we think is the right balance in general in sorting out TCG components?

replay/ files control external machine inputs and outputs to record and 
replay them: network input, keyboard, serial ports, ....
That's why replay requires some wrappers and filters in that modules.

replay also synchronizes vCPU with external interrupt/DMA 
transactions/... sources: iothread, BHs, and timers.

Without TCG replay becomes useless, because it cooperates with icount. 
Therefore it might be put under CONFIG_TCG to build kvm and other stuff.

Pavel Dovgalyuk

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 09/10/20 11:23, Philippe Mathieu-Daudé wrote:
> 
> Soft accelerator are TCG and QTest. Replay only works with soft
> accelerator. Should replay work with QTest? Is this useful?

Probably not, since we don't have icount (anymore) in qtest.

Paolo

> If replay is only usable with TCG, can we merge it into it?
> It seems quite accel-related.

Re: does make check now require TCG? Or is it a parallelism issue?

[Richard Henderson]

On 10/8/20 10:02 AM, Paolo Bonzini wrote:
> On 08/10/20 16:48, Claudio Fontana wrote:
>> on master, a build without tcg like:
>>
>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>
>> make -j120 check
>> Generating qemu-version.h with a meson_exe.py custom command
>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>> make: *** Waiting for unfinished jobs....
>>
>> qemu-system-aarch64 is required for check-block now?
> 
> No, it's not, it's an unnecessary dependency.  This will fix it:
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 5aca98e60c..1ca70d88ce 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>  check: check-block
>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))

Why doesn't the original line work?  Waiting until all of the configured
qemu-system-* executables to finish building doesn't seem wrong, even if they
won't all be used by check-block.

This replacement would seem to break e.g.

./configure --target-list=arm-softmmu

by making check-block dependent on qemu-system-x86_64, which will never be built.


r~

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 7:44 PM, Richard Henderson wrote:
> On 10/8/20 10:02 AM, Paolo Bonzini wrote:
>> On 08/10/20 16:48, Claudio Fontana wrote:
>>> on master, a build without tcg like:
>>>
>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>
>>> make -j120 check
>>> Generating qemu-version.h with a meson_exe.py custom command
>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>> make: *** Waiting for unfinished jobs....
>>>
>>> qemu-system-aarch64 is required for check-block now?
>>
>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>
>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>> index 5aca98e60c..1ca70d88ce 100644
>> --- a/tests/Makefile.include
>> +++ b/tests/Makefile.include
>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>  check: check-block
>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
> 
> Why doesn't the original line work?  Waiting until all of the configured

The original line breaks because without TCG built-in there will be no qemu-system-aarch64 to wait for.

> qemu-system-* executables to finish building doesn't seem wrong, even if they
> won't all be used by check-block.
> 
> This replacement would seem to break e.g.
> 
> ./configure --target-list=arm-softmmu
> 
> by making check-block dependent on qemu-system-x86_64, which will never be built.
> 
> 
> r~
> 

Your concern makes sense to me, it seems we just end up breaking another use case..
is there a way here to get in this makefile context the list of actual targets we are waiting for?

Ciao,

C

Re: does make check now require TCG? Or is it a parallelism issue?

[Richard Henderson]

On 10/8/20 12:53 PM, Claudio Fontana wrote:
> On 10/8/20 7:44 PM, Richard Henderson wrote:
>> On 10/8/20 10:02 AM, Paolo Bonzini wrote:
>>> On 08/10/20 16:48, Claudio Fontana wrote:
>>>> on master, a build without tcg like:
>>>>
>>>> exec '../configure' '--disable-tcg' '--enable-kvm' '--enable-hax' "$@"
>>>>
>>>> make -j120 check
>>>> Generating qemu-version.h with a meson_exe.py custom command
>>>> make: *** No rule to make target 'qemu-system-aarch64', needed by 'check-block'.  Stop.
>>>> make: *** Waiting for unfinished jobs....
>>>>
>>>> qemu-system-aarch64 is required for check-block now?
>>>
>>> No, it's not, it's an unnecessary dependency.  This will fix it:
>>>
>>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>>> index 5aca98e60c..1ca70d88ce 100644
>>> --- a/tests/Makefile.include
>>> +++ b/tests/Makefile.include
>>> @@ -140,7 +140,7 @@ QEMU_IOTESTS_HELPERS-$(CONFIG_LINUX) = tests/qemu-iotests/socket_scm_helper$(EXE
>>>  check: check-block
>>>  check-block: $(SRC_PATH)/tests/check-block.sh qemu-img$(EXESUF) \
>>>  		qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>>> -		$(patsubst %-softmmu,qemu-system-%,$(filter %-softmmu,$(TARGET_DIRS)))
>>> +		qemu-system-$(patsubst ppc64%,ppc64, $(shell uname -m))
>>
>> Why doesn't the original line work?  Waiting until all of the configured
> 
> The original line breaks because without TCG built-in there will be no qemu-system-aarch64 to wait for.

But aarch64 should not be in TARGET_DIRS (for x86 host) with --disable-tcg.
There must be some other problem.

I can reproduce this though, just as you say.

Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for lack
of accelerator.

Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
meson")?  I guess we should move the setting of TARGET_DIRS to meson as well.


r~

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Il gio 8 ott 2020, 20:05 Richard Henderson <richard.henderson@linaro.org>
ha scritto:

> Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for
> lack
> of accelerator.
>
> Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
> meson")?  I guess we should move the setting of TARGET_DIRS to meson as
> well.
>

TARGET_DIRS is pruned by Meson, I didn't add any back propagation to make
because it is not really needed; qemu-iotests only every uses the "host
architecture" QEMU binary (see tests/qemu-iotests/common.config),
check-block + --target-list has never worked.

check-tcg could use the pruned TARGET_DIRS, but it is of limited use anyway
with --disable-tcg.

At this point it may make sense to establish which config-host.mak
variables are available in the Makefile, because there's probably just a
handful. I won't have much time in the next couple of weeks though.

Paolo


> r~
>
>

[-- Attachment #2: Type: text/html, Size: 1831 bytes --]

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/8/20 8:24 PM, Paolo Bonzini wrote:
> 
> 
> Il gio 8 ott 2020, 20:05 Richard Henderson <richard.henderson@linaro.org <mailto:richard.henderson@linaro.org>> ha scritto:
> 
>     Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for lack
>     of accelerator.
> 
>     Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
>     meson")?  I guess we should move the setting of TARGET_DIRS to meson as well.
> 
> 
> TARGET_DIRS is pruned by Meson, I didn't add any back propagation to make because it is not really needed; qemu-iotests only every uses the "host architecture" QEMU binary (see tests/qemu-iotests/common.config), check-block + --target-list has never worked.
> 
> check-tcg could use the pruned TARGET_DIRS, but it is of limited use anyway with --disable-tcg.
> 
> At this point it may make sense to establish which config-host.mak variables are available in the Makefile, because there's probably just a handful. I won't have much time in the next couple of weeks though.
> 
> Paolo
> 
> 
>     r~
> 

qtests are also broken for me now with --disable-tcg build,
it _seems_ to me that TCG-only tests are being run for --disable-tcg too.

I am not sure if this is a test problem (for example tests/qtest/bios-tables-test.c): data->tcg_only
or if it is a build system problem, or some combination.

make check-qtest

...
Running test qtest-x86_64: device-plug-test
Running test qtest-x86_64: drive_del-test
Running test qtest-x86_64: tco-test
Running test qtest-x86_64: cpu-plug-test
Running test qtest-x86_64: q35-test
Running test qtest-x86_64: vmgenid-test
Running test qtest-x86_64: migration-test
Running test qtest-x86_64: test-x86-cpuid-compat
Running test qtest-x86_64: numa-test
Running test qtest-x86_64: cdrom-test
Running test qtest-x86_64: device-introspect-test
Running test qtest-x86_64: machine-none-test
Running test qtest-x86_64: qmp-test
Running test qtest-x86_64: qmp-cmd-test
Running test qtest-x86_64: qom-test
Running test qtest-x86_64: test-hmp
Running test qtest-x86_64: qos-test

qemu-system-x86_64: -accel tcg: invalid accelerator tcg
qemu-system-x86_64: falling back to QTest

ERROR:../tests/qtest/boot-sector.c:161:boot_sector_test: assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead)
ERROR qtest-x86_64: bios-tables-test - too few tests run (expected 23, got 22)
make: *** [Makefile.mtest:1298: run-test-183] Error 1
make: *** Waiting for unfinished jobs....

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 08/10/20 23:07, Claudio Fontana wrote:
> qtests are also broken for me now with --disable-tcg build,
> it _seems_ to me that TCG-only tests are being run for --disable-tcg too.
> 
> I am not sure if this is a test problem (for example tests/qtest/bios-tables-test.c): data->tcg_only
> or if it is a build system problem, or some combination.

Yes, this is due to tcg_only.  But since CONFIG_TCG is included in
config-host.mak, it should be easy to add a call to g_test_skip.

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/9/20 9:40 AM, Paolo Bonzini wrote:
> On 08/10/20 23:07, Claudio Fontana wrote:
>> qtests are also broken for me now with --disable-tcg build,
>> it _seems_ to me that TCG-only tests are being run for --disable-tcg too.
>>
>> I am not sure if this is a test problem (for example tests/qtest/bios-tables-test.c): data->tcg_only
>> or if it is a build system problem, or some combination.
> 
> Yes, this is due to tcg_only.  But since CONFIG_TCG is included in
> config-host.mak, it should be easy to add a call to g_test_skip.
> 
> Paolo
> 
> 

I am trying to wrap my head around this, but I got lost in scripts/tap-driver.pl .

I tried the following:

commit 27db7fa56fcb3d23e0f125701f65248a70fa1242
Author: Claudio Fontana <cfontana@suse.de>
Date:   Fri Oct 9 10:23:26 2020 +0200

    qtest: unbreak non-TCG builds in bios-tables-test
    
    the tests assume TCG is available, thus breaking
    for TCG-only tests, where only the TCG accelerator option
    is passed to the QEMU binary.
    
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Claudio Fontana <cfontana@suse.de>

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index e15f36c8c7..5f17289964 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -651,6 +651,13 @@ static void test_acpi_one(const char *params, test_data *data)
     char *args;
     bool use_uefi = data->uefi_fl1 && data->uefi_fl2;
 
+#ifndef CONFIG_TCG
+    if (data->tcg_only) {
+        g_test_skip("TCG disabled, skipping ACPI tcg_only test");
+        return;
+    }
+#endif /* CONFIG_TCG */
+
     if (use_uefi) {
         /*
          * TODO: convert '-drive if=pflash' to new syntax (see e33763be7cd3)
---------------------------------------------------------------------------------------------------

but I get:

cd build-nontcg
make -j12
make -j12 check-qtest

Running test qtest-x86_64: qos-test
ERROR qtest-x86_64: bios-tables-test - too few tests run (expected 23, got 22)
make: *** [Makefile.mtest:1326: run-test-187] Error 1
make: *** Waiting for unfinished jobs....

What am I missing here?

Thanks,

Claudio

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 09/10/20 12:28, Claudio Fontana wrote:
> Running test qtest-x86_64: qos-test
> ERROR qtest-x86_64: bios-tables-test - too few tests run (expected 23, got 22)
> make: *** [Makefile.mtest:1326: run-test-187] Error 1
> make: *** Waiting for unfinished jobs....
> 
> What am I missing here?

This is something else that is crashing.

You want to do (as for any other test; this should be documented)

  make -j12 check-qtest V=1

and then cut-and-paste the bios-tables-test line, which should be something like

  QTEST_QEMU_IMG=./qemu-img \
    G_TEST_DBUS_DAEMON=/home/pbonzini/work/upstream/qemu/tests/dbus-vmstate-daemon.sh \
    QTEST_QEMU_BINARY=./qemu-system-x86_64 \
    tests/qtest/bios-tables-test --tap -k

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Peter Maydell]

On Fri, 9 Oct 2020 at 12:51, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/10/20 12:28, Claudio Fontana wrote:
> > Running test qtest-x86_64: qos-test
> > ERROR qtest-x86_64: bios-tables-test - too few tests run (expected 23, got 22)
> > make: *** [Makefile.mtest:1326: run-test-187] Error 1
> > make: *** Waiting for unfinished jobs....
> >
> > What am I missing here?
>
> This is something else that is crashing.

It would be great if we could improve the error reporting for
this kind of failure, incidentally. I fairly often get
intermittents where there is nothing useful in the log
files, just one of these "too few tests run" lines (and
perhaps somewhere miles back up in the build output
interleaved with that from the other tests being run
in parallel with the one that fell over, there might
be more information, but it's basically unfindable).

thanks
-- PMM

Re: does make check now require TCG? Or is it a parallelism issue?

[Claudio Fontana]

On 10/9/20 1:49 PM, Paolo Bonzini wrote:
> On 09/10/20 12:28, Claudio Fontana wrote:
>> Running test qtest-x86_64: qos-test
>> ERROR qtest-x86_64: bios-tables-test - too few tests run (expected 23, got 22)
>> make: *** [Makefile.mtest:1326: run-test-187] Error 1
>> make: *** Waiting for unfinished jobs....
>>
>> What am I missing here?
> 
> This is something else that is crashing.
> 
> You want to do (as for any other test; this should be documented)
> 
>   make -j12 check-qtest V=1
> 
> and then cut-and-paste the bios-tables-test line, which should be something like
> 
>   QTEST_QEMU_IMG=./qemu-img \
>     G_TEST_DBUS_DAEMON=/home/pbonzini/work/upstream/qemu/tests/dbus-vmstate-daemon.sh \
>     QTEST_QEMU_BINARY=./qemu-system-x86_64 \
>     tests/qtest/bios-tables-test --tap -k
> 
> Paolo
> 

Hi Paolo,

I now just found out that bios-tables-test actually was segfaulting, but even with V=1
there was no indication or hint about it from the tests, maybe there should be?

Segfault seems to be stemming from a missing check for NULL in the free function for the test data,
with that change things seem to finally work for bios-tables-test.

Now to the next failing test.. (qos-test buzzes with no output, we'll see..)

Thanks,

Claudio

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 09/10/20 15:32, Claudio Fontana wrote:
>>   QTEST_QEMU_IMG=./qemu-img \
>>     G_TEST_DBUS_DAEMON=/home/pbonzini/work/upstream/qemu/tests/dbus-vmstate-daemon.sh \
>>     QTEST_QEMU_BINARY=./qemu-system-x86_64 \
>>     tests/qtest/bios-tables-test --tap -k
>>
>> Paolo
>>
> Hi Paolo,
> 
> I now just found out that bios-tables-test actually was segfaulting

Yes, that's what "too few tests run" usually means.

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Thomas Huth]

On 08/10/2020 20.24, Paolo Bonzini wrote:
> 
> 
> Il gio 8 ott 2020, 20:05 Richard Henderson <richard.henderson@linaro.org
> <mailto:richard.henderson@linaro.org>> ha scritto:
> 
>     Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for
>     lack
>     of accelerator.
> 
>     Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
>     meson")?  I guess we should move the setting of TARGET_DIRS to meson as
>     well.
> 
> 
> TARGET_DIRS is pruned by Meson, I didn't add any back propagation to make
> because it is not really needed; qemu-iotests only every uses the "host
> architecture" QEMU binary (see tests/qemu-iotests/common.config),
> check-block + --target-list has never worked.

I haven't tried since the meson conversion, but at least a couple of months
ago, it was perfectly fine to run configure with
--target-list=tricore-softmmu and then to run "make check-block" afterwards.

That qemu_arch setting from tests/qemu-iotests/common.config is just used
for the preferred binary, but if it is not available,
tests/qemu-iotests/check falls back to any other qemu-system-xxx binary that
it can find.

 Thomas

Re: does make check now require TCG? Or is it a parallelism issue?

[Paolo Bonzini]

On 09/10/20 09:21, Thomas Huth wrote:
> On 08/10/2020 20.24, Paolo Bonzini wrote:
>>
>>
>> Il gio 8 ott 2020, 20:05 Richard Henderson <richard.henderson@linaro.org
>> <mailto:richard.henderson@linaro.org>> ha scritto:
>>
>>     Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for
>>     lack
>>     of accelerator.
>>
>>     Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
>>     meson")?  I guess we should move the setting of TARGET_DIRS to meson as
>>     well.
>>
>>
>> TARGET_DIRS is pruned by Meson, I didn't add any back propagation to make
>> because it is not really needed; qemu-iotests only every uses the "host
>> architecture" QEMU binary (see tests/qemu-iotests/common.config),
>> check-block + --target-list has never worked.
> 
> I haven't tried since the meson conversion, but at least a couple of months
> ago, it was perfectly fine to run configure with
> --target-list=tricore-softmmu and then to run "make check-block" afterwards.

Thanks, I didn't know.  Actually it's possible to get the targets from
Makefile.ninja.  I'll send a patch.

Paolo

Re: does make check now require TCG? Or is it a parallelism issue?

[Philippe Mathieu-Daudé]

On 10/9/20 9:21 AM, Thomas Huth wrote:
> On 08/10/2020 20.24, Paolo Bonzini wrote:
>>
>>
>> Il gio 8 ott 2020, 20:05 Richard Henderson <richard.henderson@linaro.org
>> <mailto:richard.henderson@linaro.org>> ha scritto:
>>
>>      Ah, TARGET_DIRS isn't being pruned anymore when a target is disabled for
>>      lack
>>      of accelerator.
>>
>>      Paolo, side effect of 8a19980e3f ("configure: move accelerator logic to
>>      meson")?  I guess we should move the setting of TARGET_DIRS to meson as
>>      well.
>>
>>
>> TARGET_DIRS is pruned by Meson, I didn't add any back propagation to make
>> because it is not really needed; qemu-iotests only every uses the "host
>> architecture" QEMU binary (see tests/qemu-iotests/common.config),
>> check-block + --target-list has never worked.
> 
> I haven't tried since the meson conversion, but at least a couple of months
> ago, it was perfectly fine to run configure with
> --target-list=tricore-softmmu and then to run "make check-block" afterwards.
> 
> That qemu_arch setting from tests/qemu-iotests/common.config is just used
> for the preferred binary, but if it is not available,
> tests/qemu-iotests/check falls back to any other qemu-system-xxx binary that
> it can find.

I wonder if this is why the migration acceptance tests aren't run
anymore.