[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Making TCG configurable in system mode
From: |
Alvise Rigo |
Subject: |
Re: [Qemu-devel] Making TCG configurable in system mode |
Date: |
Fri, 16 Dec 2016 12:49:44 +0100 |
On Wed, Dec 14, 2016 at 10:51 PM, Paolo Bonzini <address@hidden> 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/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.
>
> 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