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