From: Paolo Bonzini <pbonzini@redhat.com>
To: Alvise Rigo <a.rigo@virtualopensystems.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
chao p peng <chao.p.peng@linux.intel.com>,
Claudio Fontana <Claudio.Fontana@huawei.com>,
VirtualOpenSystems Technical Team <tech@virtualopensystems.com>
Subject: Re: [Qemu-devel] Making TCG configurable in system mode
Date: Wed, 14 Dec 2016 16:51:54 -0500 (EST) [thread overview]
Message-ID: <391977981.4066351.1481752314886.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAH47eN3AVo-4CWN8XHhVz5F811Dc-iS8pVmW+4EW_1mvbpVgpA@mail.gmail.com>
> 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
next prev parent reply other threads:[~2016-12-14 21:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 19:30 [Qemu-devel] Making TCG configurable in system mode Alvise Rigo
2016-12-14 21:51 ` Paolo Bonzini [this message]
2016-12-16 11:49 ` Alvise Rigo
2016-12-16 11:59 ` Peter Maydell
2016-12-15 9:19 ` Laurent Vivier
2016-12-16 14:17 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=391977981.4066351.1481752314886.JavaMail.zimbra@redhat.com \
--to=pbonzini@redhat.com \
--cc=Claudio.Fontana@huawei.com \
--cc=a.rigo@virtualopensystems.com \
--cc=chao.p.peng@linux.intel.com \
--cc=qemu-devel@nongnu.org \
--cc=tech@virtualopensystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.