qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pavel Dovgalyuk
Subject: Re: does make check now require TCG? Or is it a parallelism issue?
Date: Fri, 9 Oct 2020 13:35:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]