Laurent Vivier <lviv...@redhat.com> 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/qemu-devel@nongnu.org/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
