[Qemu-devel] Making TCG configurable in system mode

[Qemu-devel] Making TCG configurable in system mode

[Alvise Rigo]

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.

I would like to hear your opinion on this, ideally to identify what
would be the best direction to follow for bringing this new feature
into QEMU.

Thank you,
alvise

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

[Paolo Bonzini]

> 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.

Yes, it sure can!  However I suggest doing it one target at a time,
because there can be tricky dependencies between helper files and
KVM support code.  It's fine as long as the configure script only
allows --disable-tcg for specific targets where it works.

IIRC my branch only covered x86 (or maybe PPC too?!?  I don't remember).

The hardest part is making sure that it doesn't bitrot, and it's hard
because we don't have CI for architectures other than x86.  But at least
Peter builds on ARM, and target submaintainers do build on PPC and s390
so it's not that bad perhaps.

> 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.

I think making qemu-system use such a library would be very hard, because
of the different implementation of qemu_ld/qemu_st in user and system
emulation.  I don't think it's important for your purpose.

Paolo

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

[Alvise Rigo]

On Wed, Dec 14, 2016 at 10:51 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> 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.
>
> Yes, it sure can!  However I suggest doing it one target at a time,
> because there can be tricky dependencies between helper files and

Indeed, doing it gradually is the right way to tackle it. I might be
back with some more concrete work. Thank you for the time being.

> KVM support code.  It's fine as long as the configure script only
> allows --disable-tcg for specific targets where it works.
>
> IIRC my branch only covered x86 (or maybe PPC too?!?  I don't remember).
>
> The hardest part is making sure that it doesn't bitrot, and it's hard
> because we don't have CI for architectures other than x86.  But at least
> Peter builds on ARM, and target submaintainers do build on PPC and s390
> so it's not that bad perhaps.

Would a CI set up just to test this feature make sense?

Thank you,
alvise

>
>> 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.
>
> I think making qemu-system use such a library would be very hard, because
> of the different implementation of qemu_ld/qemu_st in user and system
> emulation.  I don't think it's important for your purpose.
>
> Paolo

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

[Peter Maydell]

On 16 December 2016 at 11:49, Alvise Rigo <a.rigo@virtualopensystems.com> wrote:
> On Wed, Dec 14, 2016 at 10:51 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> The hardest part is making sure that it doesn't bitrot, and it's hard
>> because we don't have CI for architectures other than x86.  But at least
>> Peter builds on ARM, and target submaintainers do build on PPC and s390
>> so it's not that bad perhaps.
>
> Would a CI set up just to test this feature make sense?

If we had CI for multiple host architectures we'd just use it
routinely for everything. The difficulty is that there's nothing
public like Travis for non-x86 and historically we as a project
have not managed to maintain a local CI solution (we used to
have buildbots but their config just bitrotted).

We do include ARM and PPC in the standard set of build tests
before merging pull requests, though, so those are not completely
untested.

thanks
-- PMM

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

[Laurent Vivier]

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.

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.

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

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

[Alex Bennée]

Laurent Vivier <lvivier@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