Re: [Qemu-devel] Making TCG configurable in system mode

[Alex Bennée]

Laurent Vivier <address@hidden> writes:

> On 14/12/2016 20:30, Alvise Rigo wrote:
>> Hi all,
>>
>> I am looking at the possibility to add a new QEMU configuration option
>> to make TCG optional (in qemu-system-*). What I am exploring is a way
>> to exclude any of the TCG code not needed by KVM from the QEMU binary.
>> There has been a previous attempt in the past from Paolo Bonzini,
>> namely https://github.com/bonzini/qemu/tree/disable-tcg, that
>> eventually was not upstreamed. I was looking into this work mainly,
>> mostly to understand if the same approach can be respinned and used to
>> support all the QEMU's targets. Any input on this is welcome.
>>
>> I was also wondering if an approach could be based on the recent patch
>> series that allows to use the TCG frontend as a library --
>> https://www.mail-archive.com/address@hidden/msg415514.html.
>> Making qemu-user and qemu-system users of such a library might help in
>> having TCG optional. Obviously this solution introduces many other
>> challenges and I'm not even sure if it's actually viable.
>
> To have a library has also another interest: testing.
>
> For the moment RISU is doing a great job but it needs to be able to
> start a client (the apprentice) in a chroot. So it requires a "viable"
> TCG implementation.

FWIW you have to use a chroot. risu is simple enough to build statically
which is what I do.

That said I'd love to be able to add some test cases into "make check"
which could build a sequence of TCGops and then test things like
constant folding and other optimisations where being done correctly. I
don' know if this needs a library or just the ability to initialise the
TCG functions without everything else in a qtest binary.

> If we would have a library we could directly link the "apprentice" with
> the library and it will inject the code to test directly (without
> chroot) in the TCG engine. Moreover, I think we could use single-step
> instead of trap to synchronize master and apprentice.

Please also see the record/playback patches recently posted on the list:

  https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg01265.html

>
> We had something like that to test 680x0 [1], but the main program was
> written in C++ compiling some parts of QEMU inside, and I failed to
> recompile it last time I tried (I use RISU now).
>
> Thanks,
> Laurent
> [1] https://github.com/vivier/m68k-tester


--
Alex Bennée