From: Jan Kiszka <jan.kiszka@siemens.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Avi Kivity <avi@redhat.com>, Erik Rull <webmaster@rdsoftware.de>,
Gerd Hoffmann <kraxel@redhat.com>,
"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 09:27:51 -0300 [thread overview]
Message-ID: <4FBB8647.4060307@siemens.com> (raw)
In-Reply-To: <4FBB6BD1.9080003@siemens.com>
On 2012-05-22 07:34, Jan Kiszka wrote:
> 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
>
I've added some more details on this to the QEMU wiki, see
http://wiki.qemu.org/KVM.
BTW, if someone could have a look at the VGA diffs and resolve them,
that would be great. Gerd, what's the state of switching the BIOS?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-05-22 12:28 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
2012-05-22 12:27 ` Jan Kiszka [this message]
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=4FBB8647.4060307@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=avi@redhat.com \
--cc=kraxel@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.