All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Avi Kivity <avi@redhat.com>, Erik Rull <webmaster@rdsoftware.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
Date: Tue, 22 May 2012 07:34:57 -0300	[thread overview]
Message-ID: <4FBB6BD1.9080003@siemens.com> (raw)
In-Reply-To: <CAJSP0QXga5yxeDB5Gg8HaYNai41G6Roeh+_D1pAn5o8iEc2=Bw@mail.gmail.com>

On 2012-05-22 07:04, Stefan Hajnoczi wrote:
> On Mon, May 21, 2012 at 5:54 PM, Erik Rull <webmaster@rdsoftware.de> wrote:
>> is there a summary existing that shows up the rough or actual differences
>> between qemu --enable-kvm and qemu-kvm? I tested both versions with the same
>> compile and start options, the CPU performance results are identical, only
>> the bootup time of my guest system with qemu-kvm seemed to be a bit faster
>> (not measured, it just feeled so).

Current upstream does not enable the in-kernel irqchip of KVM by
default. This should explain the difference in boot-up times. Try
"-machine accel=kvm,kernel_irqchip=on". But the default will be on, just
like in qemu-kvm, once [1] is merged.

> 
> For production KVM instances I think it still makes sense to use
> qemu-kvm packages from your distro or qemu-kvm upstream source.
> 
> Jan Kiszka has reduced the delta between qemu.git and qemu-kvm.git to
> the point where I think the list of differences is rather small -
> maybe PCI passthrough stuff, irqfd for vhost-net (which is now also
> being upstreamed into qemu.git), and a few other things I don't know
> of.

Right, the list of differences is dramatically shrinking. As stated in
[2], soon only PCI passthrough and legacy interface dependencies on
qemu-kvm will be the remaining reasons to use it. If we are lucky, PCI
passthrough will also make it into upstream for QEMU 1.2, we are working
on this.

> 
> For development most patches should be against qemu.git unless they
> have a dependency on qemu-kvm.git code.

Yes, unless you are working on the upstream merge itself, there is
practically no reason anymore to develop against qemu-kvm directly.

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91171
[2] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91026

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-05-22 10:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 16:54 [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm? Erik Rull
2012-05-22 10:04 ` Stefan Hajnoczi
2012-05-22 10:34   ` Jan Kiszka [this message]
2012-05-22 12:27     ` Jan Kiszka
2012-05-22 13:05       ` Gerd Hoffmann
2012-05-22 16:12       ` Erik Rull
2012-05-22 17:56         ` Jan Kiszka
  -- strict thread matches above, loose matches on Subject: below --
2012-05-21 16:55 Erik Rull

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=4FBB6BD1.9080003@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=webmaster@rdsoftware.de \
    /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.