qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 4/4] meson: Warn when TCI is selected but TCG backend is a


From: Alex Bennée
Subject: Re: [PATCH v4 4/4] meson: Warn when TCI is selected but TCG backend is available
Date: Wed, 27 Jan 2021 19:52:26 +0000
User-agent: mu4e 1.5.7; emacs 28.0.50

Stefan Weil <sw@weilnetz.de> writes:

> Am 26.01.21 um 23:39 schrieb Richard Henderson:
>
>> On 1/26/21 9:44 AM, Stefan Weil wrote:
>>> I was not talking about the TODO assertions. When I wrote TCI, I only 
>>> enabled
>>> and included code which was triggered by my testing - that's why I said the
>>> productive code lines have 100 % test coverage. TODO assertions are not
>>> productive code, but debug code which were made to detect new test cases. 
>>> They
>>> were successful, too, because they were triggered by some tests in `make
>>> check-tcg`.
>> The TODO assertions are all bugs.
>>
>> Any *real* dead code detection should have been done in
>> tcg/tci/tcg-target.c.inc.  What's interpreted in tcg/tci.c should be exactly
>> what is produced on the other side, and you are producing more than you are
>> consuming.
>
>
> Unless the TCG opcodes in tcg/tci/tcg-target.c.inc are used in real-live 
> scenarios, they are dead code, too.

For example - debian-buster (arm64) running ffmpeg:

  alex.bennee@8cd150a4b35d:~/lsrc/qemu.git/builds/all.tci$ ./qemu-aarch64 
/usr/bin/ffmpeg -i theora.mkv theora.webm
  TODO ../../tcg/tci.c:882: tcg_qemu_tb_exec()
  ../../tcg/tci.c:882: tcg fatal error
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

> Writing a test case which produces them directly (not for some real 
> architecture) is not a real-live scenario.
>
> And the remaining TODO assertions are a good indicator that the current 
> tests are incomplete for native TCG because they obviously don't cover 
> all TCG opcodes.

That's because check-tcg isn't a comprehensive test suite and expecting
it to be misses the point of it. It was added to make it easy to add new
test cases and remove some of the burden off maintainers having their
own zoo of test binaries. It has slowly grown as directed test cases
were written while bug hunting and sometimes when new features where
added. It will never be a comprehensive exercising of the CPU emulation
although some architectures have more coverage than others. For example
MIPs has a bunch of ISA level tests as part of check-tcg but most of the
ARM ISA validation is done externally using the RISU random instruction
testing tool.

Besides you've just argued writing a test case that targets missing
functionality in TCI would somehow be cheating as it's not a "real-live"
scenario.

I don't mind either way - the fact that TCI is useful to people is cool
and more power to them. But lets not pretend it is a fully functional
and maintained backend because it has obviously got some major holes. If
it ends up being a drag on efforts to maintain and improve the TCG then
we have to question why we are keeping it in. Being able to run
emulation on esoteric hardware without a real backend is a party trick
at best. The other use-cases that have been mentioned could be solved
with investing some effort in the rest of the TCG code.

-- 
Alex Bennée



reply via email to

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