public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Cc: Carsten Otte <cotte@de.ibm.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	kvm-devel <kvm@vger.kernel.org>,
	Hollis Blanchard <hollisb@us.ibm.com>,
	Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Date: Wed, 12 Nov 2008 23:48:19 +0100	[thread overview]
Message-ID: <491B5D33.7060601@bellard.org> (raw)
In-Reply-To: <1226527840-14183-1-git-send-email-aliguori@us.ibm.com>

Anthony Liguori wrote:
> Unlike kqemu, KVM does not use TCG at all when accelerating QEMU.  Having TCG
> present is not a problem when using KVM on x86.  x86 already has TCG host and
> target support and it's quite convenient to be able to disable/enable KVM and
> compare it to TCG when debugging.
> 
> KVM also supports architectures that do not have TCG host and target support
> such as ia64, s390, and PPC[1].  For these architectures, TCG is an inhibitor
> for upstream inclusion.
> 
> TCG is pretty well isolated in QEMU so building these targets without TCG
> should be easy enough.  This breaks down in exec.c though.  There is a lot of
> TCG specific code in exec.c, but also a lot of code that KVM needs.
> 
> This patch moves the non-TCG specific bits of exec.c into a separate file,
> exec-all.c.  This makes it relatively easy to build QEMU without TCG support.
> More patches will come to complete this work but the exec.c bits are probably
> 95% of what is needed.
> 
> The remaining bits are some general cleanups where layering has been violated
> and the introduction of a new -kvm subtarget, similar to -softmmu or
>  -linux-user.  This target will not have TCG support and only support KVM.
> However, before going down that path, I wanted to see if anyone objected to this
> bit of the cleanup.
> 
> Any objections?

I suggest to go even further: there should be a way in QEMU to define
CPUs which do not rely on the dynamic translator and this choice should
be doable at runtime (i.e. not with a bunch of #ifdefs as you may do
it). This way you could not only plug KVM CPUs without having the
equivalent TCG one, but also CPUs from other sources (i.e. the x86
interpreter of malc, or the cycle accurate PTLsim x86 emulator).

Fabrice.


  reply	other threads:[~2008-11-12 22:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-12 22:10 [PATCH][RFC] Split non-TCG bits out of exec.c Anthony Liguori
2008-11-12 22:48 ` Fabrice Bellard [this message]
2008-11-12 22:53   ` [Qemu-devel] " Anthony Liguori
2008-11-13 13:51 ` andrzej zaborowski
2008-11-13 16:18   ` Anthony Liguori
2008-11-14  3:12     ` andrzej zaborowski
2008-11-14  3:18       ` Anthony Liguori
2008-11-14 13:45         ` andrzej zaborowski
2008-11-14  4:03 ` Jamie Lokier
2008-11-14  9:58   ` Avi Kivity
2008-11-14 13:23     ` Jamie Lokier
2008-11-16 13:07       ` Avi Kivity
2008-11-17  3:57         ` Jamie Lokier
2008-11-14 13:58   ` Anthony Liguori
2008-11-14 14:07   ` Anthony Liguori
2008-11-14 23:13     ` Jamie Lokier
2008-11-14 23:20       ` Anthony Liguori

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=491B5D33.7060601@bellard.org \
    --to=fabrice@bellard.org \
    --cc=aliguori@us.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=hollisb@us.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox