All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
@ 2012-05-21 16:54 Erik Rull
  2012-05-22 10:04 ` Stefan Hajnoczi
  0 siblings, 1 reply; 8+ messages in thread
From: Erik Rull @ 2012-05-21 16:54 UTC (permalink / raw)
  To: qemu-devel

Hi all,

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).

Thanks.

Best regards,

Erik

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  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
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2012-05-22 10:04 UTC (permalink / raw)
  To: Erik Rull; +Cc: Jan Kiszka, Marcelo Tosatti, qemu-devel, Avi Kivity

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).

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.

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

Stefan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  2012-05-22 10:04 ` Stefan Hajnoczi
@ 2012-05-22 10:34   ` Jan Kiszka
  2012-05-22 12:27     ` Jan Kiszka
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Kiszka @ 2012-05-22 10:34 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: Avi Kivity, Erik Rull, qemu-devel, Marcelo Tosatti

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  2012-05-22 10:34   ` Jan Kiszka
@ 2012-05-22 12:27     ` Jan Kiszka
  2012-05-22 13:05       ` Gerd Hoffmann
  2012-05-22 16:12       ` Erik Rull
  0 siblings, 2 replies; 8+ messages in thread
From: Jan Kiszka @ 2012-05-22 12:27 UTC (permalink / raw)
  To: Stefan Hajnoczi
  Cc: Avi Kivity, Erik Rull, Gerd Hoffmann, qemu-devel, Marcelo Tosatti

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  2012-05-22 12:27     ` Jan Kiszka
@ 2012-05-22 13:05       ` Gerd Hoffmann
  2012-05-22 16:12       ` Erik Rull
  1 sibling, 0 replies; 8+ messages in thread
From: Gerd Hoffmann @ 2012-05-22 13:05 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: Stefan Hajnoczi, Avi Kivity, Erik Rull, qemu-devel, Marcelo Tosatti

  Hi,

> BTW, if someone could have a look at the VGA diffs and resolve them,
> that would be great.

There isn't much ...

--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -31,8 +31,8 @@

-#define VBE_DISPI_MAX_XRES              1600
-#define VBE_DISPI_MAX_YRES              1200
+#define VBE_DISPI_MAX_XRES              2560
+#define VBE_DISPI_MAX_YRES              1600

The vgabios (both lgpl'ed and seavgabios) filters the mode list by
available memory anyway, so there is no need to keep those low enougth
that the xmax * ymax * 32bpp fits into vga memory.  And when the vgamem
becomes configurable (see below) this will be moot anyway.

I think we should just make them large enougth that they are practically
unlimited.  Those are 16bit registers in virtual hardware.  Guess we
better leave the high bit clear to avoid possible issues with signed
integers.  So (1<<14) aka 16384 maybe?  Or 16000?

-#define VGA_RAM_SIZE (8192 * 1024)
+#define VGA_RAM_SIZE (16 * 1024 * 1024)

That one is more tricky as it breaks migration.  I guess qemu has to
stick to 8M by default for that reason.  We certainly can make the vga
memory size configurable via property though, so you can easily go for
16M or even more (or 1M to reduce the memory footprint of your guests
when using text mode only).

> Gerd, what's the state of switching the BIOS?

Postponed to 1.2.  Too risky for 1.1, also malc vetoed the switch
without seavgabios supporting the vesa protected mode interface which
still needs to be done.

cheers,
  Gerd

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  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
  1 sibling, 1 reply; 8+ messages in thread
From: Erik Rull @ 2012-05-22 16:12 UTC (permalink / raw)
  To: Jan Kiszka
  Cc: qemu-devel, Stefan Hajnoczi, Marcelo Tosatti, Avi Kivity, Gerd Hoffmann

Jan Kiszka wrote:
> 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
>

Hi all,

thanks a lot!

I don't use PCI device assignment - so the missing irqchip-default-option 
should be the biggest difference between these two versions, right?

Best regards,

Erik

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
  2012-05-22 16:12       ` Erik Rull
@ 2012-05-22 17:56         ` Jan Kiszka
  0 siblings, 0 replies; 8+ messages in thread
From: Jan Kiszka @ 2012-05-22 17:56 UTC (permalink / raw)
  To: Erik Rull
  Cc: qemu-devel, Stefan Hajnoczi, Marcelo Tosatti, Avi Kivity, Gerd Hoffmann

On 2012-05-22 13:12, Erik Rull wrote:
> Jan Kiszka wrote:
>> 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
>>
> 
> Hi all,
> 
> thanks a lot!
> 
> I don't use PCI device assignment - so the missing irqchip-default-option 
> should be the biggest difference between these two versions, right?

And the lacking MSI support when irqchip is on. If that matters depends
on your workload.

Jan

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
@ 2012-05-21 16:55 Erik Rull
  0 siblings, 0 replies; 8+ messages in thread
From: Erik Rull @ 2012-05-21 16:55 UTC (permalink / raw)
  To: qemu-devel

Hi all,

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).

Thanks.

Best regards,

Erik

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2012-05-22 17:56 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2012-05-22 13:05       ` Gerd Hoffmann
2012-05-22 16:12       ` Erik Rull
2012-05-22 17:56         ` Jan Kiszka
2012-05-21 16:55 Erik Rull

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.