[Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Hi,

I'm new to the list so let me introduce myself. I am one of the
developers for TurnKey Linux, a new opensource project that develops a
family of lightweight installable live CDs optimized for various
server-type tasks including LAMP, Ruby on Rails, Django, Joomla, Drupal,
MediaWiki, and others: http://www.turnkeylinux.org/

This type of pre-integrated, ready-to-use system is typically called a
software appliance: http://en.wikipedia.org/wiki/Software_appliance

We use qemu heavily in our development/testing. We find it's better
suited as a scriptable primitive than other opensource alternative such
as VirtualBox. Thankfully the KVM fork has gotten rid of the performance
disadvantage qemu used to suffer from.

Anyhow, I've recently explored the latest release of VirtualBox (which I
understand is based on qemu).

Two major changes in version 2.1 caught my attention:

1) complex setup is no longer required for "bridged" networking:

   This is a big win for us as the former networking setup complexity
   indirectly made TurnKey appliances much more difficult for regular
   users to set up.

   VirtualBox came to its senses and realized the tap configuration mess
   was way too complex for most users and cumbersome even for advanced
   users. Also, I don't think it worked with wireless NICs.

   In the latest release, "host interface networking" just works. The
   user simply selects which NIC to connect the guest to (e.g., eth0)
   and they're done.

   Behinds the scenes VirtualBox is putting your NIC into promisc mode to
   sniff packets to guests and injecting packets directly to the NIC.
   Essentially it creates a virtual NIC in software.

   This works without root privileges somehow, probably by taking
   advantage of new infrastructure in the VirtualBox device driver.

2) improved support for running 64bit guests on 32bit hosts

   On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
   seconds.

   By contrast, I booted the same CD under qemu-system-x86_64 in
   257 seconds, or 5 times slower...

These are dramatic improvements in usability and I'm curious whether it
is likely that these changes will find there way to qemu? I know that
both projects are under the same opensource license and share quite a
bit of code but I don't really know too much about the internals of both
projects so I'm not sure how difficult this would be to accomplish
technically...

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Samuel Thibault]

Liraz Siri, le Wed 24 Dec 2008 14:48:13 +0200, a écrit :
> 2) improved support for running 64bit guests on 32bit hosts
> 
>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>    seconds.
>    By contrast, I booted the same CD under qemu-system-x86_64 in
>    257 seconds, or 5 times slower...

Mmm, is your native processor 64bit-capable?

Samuel

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Alexey Eremenko]

On Wed, Dec 24, 2008 at 1:17 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Liraz Siri, le Wed 24 Dec 2008 14:48:13 +0200, a écrit :
>> 2) improved support for running 64bit guests on 32bit hosts
>>
>>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>>    seconds.
>>    By contrast, I booted the same CD under qemu-system-x86_64 in
>>    257 seconds, or 5 times slower...
>
> Mmm, is your native processor 64bit-capable?

Of course his Core 2 is 64-bit :) LOL

-- 
-Alexey Eromenko "Technologov"

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Alexey Eremenko]

On Wed, Dec 24, 2008 at 12:48 PM, Liraz Siri <liraz@turnkeylinux.org> wrote:
> Hi,
>
> I'm new to the list so let me introduce myself. I am one of the
> developers for TurnKey Linux, a new opensource project that develops a
> family of lightweight installable live CDs optimized for various
> server-type tasks including LAMP, Ruby on Rails, Django, Joomla, Drupal,
> MediaWiki, and others: http://www.turnkeylinux.org/
>
> This type of pre-integrated, ready-to-use system is typically called a
> software appliance: http://en.wikipedia.org/wiki/Software_appliance
>
> We use qemu heavily in our development/testing. We find it's better
> suited as a scriptable primitive than other opensource alternative such
> as VirtualBox. Thankfully the KVM fork has gotten rid of the performance
> disadvantage qemu used to suffer from.
>
> Anyhow, I've recently explored the latest release of VirtualBox (which I
> understand is based on qemu).
>
> Two major changes in version 2.1 caught my attention:
>
> 1) complex setup is no longer required for "bridged" networking:
>
>   This is a big win for us as the former networking setup complexity
>   indirectly made TurnKey appliances much more difficult for regular
>   users to set up.
>
>   VirtualBox came to its senses and realized the tap configuration mess
>   was way too complex for most users and cumbersome even for advanced
>   users. Also, I don't think it worked with wireless NICs.
>
>   In the latest release, "host interface networking" just works. The
>   user simply selects which NIC to connect the guest to (e.g., eth0)
>   and they're done.
>
>   Behinds the scenes VirtualBox is putting your NIC into promisc mode to
>   sniff packets to guests and injecting packets directly to the NIC.
>   Essentially it creates a virtual NIC in software.
>
>   This works without root privileges somehow, probably by taking
>   advantage of new infrastructure in the VirtualBox device driver.

Yes, the new networking option makes life easier - and it works
without root if you are part of "vboxusers" group on your PC.
This feature is unlikely to be copied, because it is part of the
"vboxdrv" driver + part of the GUI.

However, other features, such as improved ICMP support via NAT, may
eventually make it into Qemu/KVM.
-- 
-Alexey Eromenko "Technologov"

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Paul Brook]

> 1) complex setup is no longer required for "bridged" networking:
>
>    This works without root privileges somehow, probably by taking
>    advantage of new infrastructure in the VirtualBox device driver.

You need root privileges to load the random kernel modules required to d this. 
Not going to happen for qemu.

> 2) improved support for running 64bit guests on 32bit hosts
>
>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>    seconds.
>
>    By contrast, I booted the same CD under qemu-system-x86_64 in
>    257 seconds, or 5 times slower...

You're comparing apples to oranges. Virtualbox uses virtualization, qemu use 
emulation. I suspect if you boot a 64-bit OS you'll find things significantly 
slower.

If you're running a 32-bit operating system on a 64-bit machine I'm completely 
uninterested. Run a proper operating system that actually supports your 
hardware.

If you want 32-bit on 64-bit virtualization you need to talk to the KVM 
people. I doubt you'll find much interest though. Any hardware that supports 
KVM is already 64-bit, and you're almost entirely targetting obsolete 
hardware.

On a related note, VirtualBox has the same problem as kqemu: Out of tree 
kernel modules are just plain wrong. A large proportion of the linux 
community (me included) isn't going to take it seriously until it's [aiming 
to be] merged into mainstream kernels. To do that you probably need to make 
it use the KVM interface.

> These are dramatic improvements in usability and I'm curious whether it
> is likely that these changes will find there way to qemu? I know that
> both projects are under the same opensource license

Not quite true. IIRC VirtualBox is released under a proprietary licence, with 
some parts dual licenced as GPL. QEMU is a mixture of GPL, LGPL and BSD. This 
discrepancy tends to disourage cooperation.

Paul

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Paul Brook wrote:

> You need root privileges to load the random kernel modules required to d this. 
> Not going to happen for qemu.

There's at least one counter-precedent. qemu takes advantage of kqemu
which is also a "random kernel module". How would supporting a kernel
module that simplified a bridged networking be any different?

Also, qemu seems to require root privileges to setup tap devices, so it
wouldn't be a first.

BTW, we don't need this for our own use. We setup VDE + tap devices
bridged to the network interface. Works great, at least for NICs that
support bridging. Also it doesn't require root privileges, only
permissions to connect to the unix socket vde is listening on.
Unfortunately, for most users setting something like this up would
probably be a challenge.

It would be beneficial if qemu supported an easier way to set this up  -
like VirtualBox.

>> 2) improved support for running 64bit guests on 32bit hosts
>>
>>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>>    seconds.
>>
>>    By contrast, I booted the same CD under qemu-system-x86_64 in
>>    257 seconds, or 5 times slower...
> 
> You're comparing apples to oranges. Virtualbox uses virtualization, qemu use 
> emulation. I suspect if you boot a 64-bit OS you'll find things significantly 
> slower.

Sorry if I wasn't clear. I am booting a 64-bit OS. I tested booting an
amd64 Lenny live CD and an amd64 Ubuntu hardy desktop. My hardware
supports 64bits but I'm still using a 32bit operating system.

I don't really understand the implementation VirtualBox uses to
accomplish running 64bit VM guests on a 32bit host. Is it possible
VirtualBox have figured out how to run 64bit instructions on a host
running in 32bit mode? (otherwise they'll need to be doing some kind of
emulation)

Testing this VirtualBox feature on hardware that doesn't support 64bit
instructions will be revealing...

> If you're running a 32-bit operating system on a 64-bit machine I'm completely 
> uninterested. Run a proper operating system that actually supports your 
> hardware.

That's your choice, but keep in mind there are many types of users who
have to work under different conditions...

> Not quite true. IIRC VirtualBox is released under a proprietary licence, with 
> some parts dual licenced as GPL. QEMU is a mixture of GPL, LGPL and BSD. This 
> discrepancy tends to disourage cooperation.

According to their website VirtualBox OSE (the opensource edition) is in
fact licensed under the GPL.

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Jernej Simončič]

On Wednesday, December 24, 2008, 15:33:51, Liraz Siri wrote:

> I don't really understand the implementation VirtualBox uses to
> accomplish running 64bit VM guests on a 32bit host. Is it possible
> VirtualBox have figured out how to run 64bit instructions on a host
> running in 32bit mode? (otherwise they'll need to be doing some kind of
> emulation)

VirtualBox isn't the only one that supports this - VMWare also lets
you run 64bit guests on 32bit hosts.

> Testing this VirtualBox feature on hardware that doesn't support 64bit
> instructions will be revealing...

AFAIK, VirtualBox requires hardware virtualisation support for running
64bit guests, so you'll have to find a Core Duo CPU somewhere (which
are AFAIK, the only 32-bit CPUs that have hardware virtualisation
support).

-- 
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

If you drop something, it will never reach the ground.
       -- Femo's Law Of Automotive Engine Repairing

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Paul Brook]

On Wednesday 24 December 2008, Liraz Siri wrote:
> Paul Brook wrote:
> > You need root privileges to load the random kernel modules required to d
> > this. Not going to happen for qemu.
>
> There's at least one counter-precedent. qemu takes advantage of kqemu
> which is also a "random kernel module". How would supporting a kernel
> module that simplified a bridged networking be any different?

Well, I'm not a great fan of kqemu to start with. I suspect it may end up 
being removed sooner rather than later.

Networking is not a qemu specific feature. The first thing you need to do is 
convince the kernel folks that this is a useful feature, and get it 
implemented there. Then we can make qemu use that interface.
What you've described sounds a lot like the pcap interface, which has its own 
set of problems.

If your main argument is "users are too dumb to configure a bridge" then 
you're arguing from a fairly weak position. The answer tends to be that you 
need to make your configuration tools suck less.

Paul

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Anthony Liguori]

Liraz Siri wrote:
> Hi,
>
> Two major changes in version 2.1 caught my attention:
>
> 1) complex setup is no longer required for "bridged" networking:
>
>    This is a big win for us as the former networking setup complexity
>    indirectly made TurnKey appliances much more difficult for regular
>    users to set up.
>
>    VirtualBox came to its senses and realized the tap configuration mess
>    was way too complex for most users and cumbersome even for advanced
>    users. Also, I don't think it worked with wireless NICs.
>
>    In the latest release, "host interface networking" just works. The
>    user simply selects which NIC to connect the guest to (e.g., eth0)
>    and they're done.
>
>    Behinds the scenes VirtualBox is putting your NIC into promisc mode to
>    sniff packets to guests and injecting packets directly to the NIC.
>    Essentially it creates a virtual NIC in software.
>   

This is not how it works.  They have their own special tap kernel module.

>    This works without root privileges somehow, probably by taking
>    advantage of new infrastructure in the VirtualBox device driver.
>   

Because they load a new kernel module and the set the perms of it's 
device to be open to any user.  This would never be allowed in upstream 
Linux though.  Putting arbitrary packets on the physical network is 
considered a superuser operation.  Since you have to be root to bind() 
to a port < 1024, raw traffic obviously allows you to do this.

FWIW, if you use virt-manager, then setting up networking is a breeze.  
The reason you think networking is hard in QEMU is that you are 
interacting with it at the wrong level.

> 2) improved support for running 64bit guests on 32bit hosts
>
>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>    seconds.
>
>    By contrast, I booted the same CD under qemu-system-x86_64 in
>    257 seconds, or 5 times slower...
>   

Well you're comparing virtualization to emulation.  A better comparison 
would be a 32-bit vs 32-bit VM using -enable-kvm.  I'm sure QEMU will 
hold it's own or even do better.  Historically, VirtualBox has not 
performed competitively against other VMMs.

KVM doesn't support running 64-bit guests on 32-bit hosts.  If someone 
was sufficiently motivated, they could write patches to KVM and they 
could possibly be accepted.  VirtualBox is of no help here.

I think the value of running 64-bit guests on a 32-bit host is marginal, 
at best.  I don't see a lot of eagerness among developers to support 
this configuration.

> These are dramatic improvements in usability and I'm curious whether it
> is likely that these changes will find there way to qemu?

Only if Sun decides to start contributing those changes back to QEMU.  
You'll have to talk to the VirtualBox developers to see what their plans 
are with that.

>  I know that
> both projects are under the same opensource license and share quite a
> bit of code

Sharing implies a two-way exchange.  In reality, VirtualBox has taken a 
bunch of QEMU code and AFAIK has not shared any of their changes back 
with the QEMU community.  They are completely entitled to do this of 
course based on the licensing of QEMU.

Some of their most interesting changes (like SATA emulation, rewritten 
USB emulation) remain available only in their closed source version.  I 
find that extremely unfortunate because that would be some of the 
easiest and most useful code to try to merge from their project.

Regards,

Anthony Liguori

>  but I don't really know too much about the internals of both
> projects so I'm not sure how difficult this would be to accomplish
> technically...
>
> Cheers,
> Liraz
>
>
>   

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Paul Brook wrote:

> Well, I'm not a great fan of kqemu to start with. I suspect it may end up 
> being removed sooner rather than later.

Yeah, kqemu only seems to be useful for users that can't use KVM due to
lack of hardware support.

> Networking is not a qemu specific feature. The first thing you need to do is 
> convince the kernel folks that this is a useful feature, and get it 
> implemented there. Then we can make qemu use that interface.
> What you've described sounds a lot like the pcap interface, which has its own 
> set of problems.
> 
> If your main argument is "users are too dumb to configure a bridge" then 
> you're arguing from a fairly weak position. The answer tends to be that you 
> need to make your configuration tools suck less.

Good point.

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Anthony Liguori]

Liraz Siri wrote:
> Paul Brook wrote:
>
>   
>> You need root privileges to load the random kernel modules required to d this. 
>> Not going to happen for qemu.
>>     
>
> There's at least one counter-precedent. qemu takes advantage of kqemu
> which is also a "random kernel module". How would supporting a kernel
> module that simplified a bridged networking be any different?
>   

I would object strongly to any new code in QEMU that was relying on a 
kernel module that had no chance of making it upstream.

FWIW, we could simplify bridged networking in QEMU but it would require 
root privileges or a setuid helper.

All someone has to do is write an /etc/qemu-ifup and /etc/qemu-ifdown 
that create a bridged interface.  I'd be happy to take patches to pass 
additional parameters to the script.  For instance, you could do:

-net tap,mode=bridging,if=eth0

And it could Just Work.  /etc/qemu-ifup and /etc/qemu-ifdown would have 
to be setuid helpers of course and they should enforce some sort of 
group access control.

> Also, qemu seems to require root privileges to setup tap devices, so it
> wouldn't be a first.
>   

It does, but there's no reason we could extend tap just a little bit so 
that it got a file descriptor from the /etc/qemu-ifup script.

> BTW, we don't need this for our own use. We setup VDE + tap devices
> bridged to the network interface. Works great, at least for NICs that
> support bridging.

AFAIK, VDE doesn't actually get a tap file descriptor.  Instead it sends 
all traffic to a daemon for processing.  This implies that performance 
will never be as good as tap.

Regards,

Anthony Liguori

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Anthony Liguori wrote:

 > FWIW, if you use virt-manager, then setting up networking is a breeze.
> The reason you think networking is hard in QEMU is that you are
> interacting with it at the wrong level.

For my purposes, the libvirt stuff just gets in the way, but last time I
tried the libvirt based front-end tools were a mess. I didn't try the
latest upstream versions though, just the packages in my distribution's
repository (8.04).

>> 2) improved support for running 64bit guests on 32bit hosts
>>
>>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>>    seconds.
>>
>>    By contrast, I booted the same CD under qemu-system-x86_64 in
>>    257 seconds, or 5 times slower...
>>   

> Well you're comparing virtualization to emulation.  A better comparison
> would be a 32-bit vs 32-bit VM using -enable-kvm.  I'm sure QEMU will
> hold it's own or even do better.  Historically, VirtualBox has not
> performed competitively against other VMMs.

For a 32bit host and a 32bit guest Qemu/KVM performs better than
VirtualBox, at least in my testing. It wasn't a dramatic difference though.

> KVM doesn't support running 64-bit guests on 32-bit hosts.  If someone
> was sufficiently motivated, they could write patches to KVM and they
> could possibly be accepted.  VirtualBox is of no help here.
> 
> I think the value of running 64-bit guests on a 32-bit host is marginal,
> at best.  I don't see a lot of eagerness among developers to support
> this configuration.

Supporting that configuration is mostly useful in aiding gradual
transitions from 32bit to 64bit. Due to dependency chains most users are
still running 32bit hosts right now. I'm not sure it has any long-term
usefulness.

> Only if Sun decides to start contributing those changes back to QEMU. 
> You'll have to talk to the VirtualBox developers to see what their plans
> are with that.
> 
> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
> bunch of QEMU code and AFAIK has not shared any of their changes back
> with the QEMU community.  They are completely entitled to do this of
> course based on the licensing of QEMU.
> 
> Some of their most interesting changes (like SATA emulation, rewritten
> USB emulation) remain available only in their closed source version.  I
> find that extremely unfortunate because that would be some of the
> easiest and most useful code to try to merge from their project.

That's really too bad. I guess at some level their xVM platform is in
competition with qemu/KVM/libvirt so maybe their interests don't align
with the greater good here.

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Anthony Liguori wrote:

> FWIW, we could simplify bridged networking in QEMU but it would require
> root privileges or a setuid helper.

A setuid helper would probably do the trick. You need root privileges to:

1) create the tap device (with appropriate ownership)
2) bridge it to your NIC

Once you take care of that qemu will happily connect to the user-end of
the configured tap device without requiring any special privileges::

    qemu -net nic -net tap,ifname=tap0

> All someone has to do is write an /etc/qemu-ifup and /etc/qemu-ifdown
> that create a bridged interface.  I'd be happy to take patches to pass
> additional parameters to the script.  For instance, you could do:
> 
> -net tap,mode=bridging,if=eth0

The KVM package on Ubuntu is configured to run this tap configuration
script by default::

    #!/bin/sh

    switch=$(ip route ls | awk '/^default / { for(i=0;i<NF;i++) { if
($(i) == "dev") print $(i+1) }}')
    /sbin/ifconfig $1 0.0.0.0 up
    /usr/sbin/brctl addif ${switch} $1
    exit 0

Trouble is, that doesn't work without root privileges, and I understand
running qemu with root privileges isn't a really good idea given it's
complexity.

> And it could Just Work.  /etc/qemu-ifup and /etc/qemu-ifdown would have
> to be setuid helpers of course and they should enforce some sort of
> group access control.

If I understand correctly even if qemu-ifup/qemu-ifdown were setuid
helpers qemu would still need root privileges to create tap devices. You
have to set that up before you launch qemu.

> AFAIK, VDE doesn't actually get a tap file descriptor.  Instead it sends
> all traffic to a daemon for processing.  This implies that performance
> will never be as good as tap.

Thats true. The file descriptor VDE passes to qemu is to a unix socket
connected to an instance of the vde_switch daemon.

In most usage scenarios vde_switch handling packets in userspace is
probably not going to be the bottleneck. In a simple test (e.g., ping -f
-s 31000) I manage to shovel 90Mbit/s full duplex through a single VDE
switch. Granted if I connect the guest directly to the tap interface my
test maxes out at 160Mbit/s full duplex so there is definitely a
performance penalty involved.

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Anthony Liguori wrote:

> FWIW, if you use virt-manager, then setting up networking is a breeze.
> The reason you think networking is hard in QEMU is that you are
> interacting with it at the wrong level.

For my purposes, the libvirt stuff just gets in the way, but last time I
tried the libvirt based front-end tools were a mess. I didn't try the
latest upstream versions though, just the packages in my distribution's
repository (8.04).

>> 2) improved support for running 64bit guests on 32bit hosts
>>
>>    On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48
>>    seconds.
>>
>>    By contrast, I booted the same CD under qemu-system-x86_64 in
>>    257 seconds, or 5 times slower...
>>   

> Well you're comparing virtualization to emulation.  A better comparison
> would be a 32-bit vs 32-bit VM using -enable-kvm.  I'm sure QEMU will
> hold it's own or even do better.  Historically, VirtualBox has not
> performed competitively against other VMMs.

For a 32bit host and a 32bit guest Qemu/KVM performs better than
VirtualBox, at least in my testing. It wasn't a dramatic difference though.

> KVM doesn't support running 64-bit guests on 32-bit hosts.  If someone
> was sufficiently motivated, they could write patches to KVM and they
> could possibly be accepted.  VirtualBox is of no help here.
> 
> I think the value of running 64-bit guests on a 32-bit host is marginal,
> at best.  I don't see a lot of eagerness among developers to support
> this configuration.

Supporting that configuration is mostly useful in aiding gradual
transitions from 32bit to 64bit. Due to dependency chains most users are
still running 32bit hosts right now. I'm not sure it has any long-term
usefulness.

> Only if Sun decides to start contributing those changes back to QEMU. 
> You'll have to talk to the VirtualBox developers to see what their plans
> are with that.
> 
> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
> bunch of QEMU code and AFAIK has not shared any of their changes back
> with the QEMU community.  They are completely entitled to do this of
> course based on the licensing of QEMU.
> 
> Some of their most interesting changes (like SATA emulation, rewritten
> USB emulation) remain available only in their closed source version.  I
> find that extremely unfortunate because that would be some of the
> easiest and most useful code to try to merge from their project.

That's really too bad. I guess at some level their xVM platform is in
competition with qemu/KVM/libvirt so maybe their interests don't align
with the greater good here.

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Jamie Lokier]

Paul Brook wrote:
> Any hardware that supports KVM is already 64-bit, and you're almost
> entirely targetting obsolete hardware.

32-bit hardware is still in use.  My laptop is just over 2 years old,
and there were *no* 64-bit Intel laptop CPUs available when I bought
it (or I would have bought one).

I use 32-bit KVM very often on my laptop, for OS compatibility
testing, Windows development, BSD development, old Linux development
and binary software packaging.

(I also use QEMU, with and without KQEMU, to run older guest OSes that
KVM does not work for.)

To say 32-bit KVM-capable hardware is obsolete implies all _relevant_
laptop users buy new ones every less than 2 years, which sounds
ridiculous to me.

-- Jamie

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[C.W. Betts]

On Dec 24, 2008, at 7:33 AM, Liraz Siri wrote:
>
>
> I don't really understand the implementation VirtualBox uses to
> accomplish running 64bit VM guests on a 32bit host. Is it possible
> VirtualBox have figured out how to run 64bit instructions on a host
> running in 32bit mode? (otherwise they'll need to be doing some kind  
> of
> emulation)
>
> Testing this VirtualBox feature on hardware that doesn't support 64bit
> instructions will be revealing...

It probably uses something similar to the way the Mac OS X 10.4 and  
10.5 kernel works.  All versions of Mac OS X (excluding the upcoming  
Snow Leopard, and then only supported on select hardware) use a 32-bit  
Kernel, but on 10.4, and more so on 10.5, it can run 64-bit apps.  How  
it does this, I don't know, but it is possible that VirtualBox is  
using the same hardware calls.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Avi Kivity]

Liraz Siri wrote:
> I don't really understand the implementation VirtualBox uses to
> accomplish running 64bit VM guests on a 32bit host. Is it possible
> VirtualBox have figured out how to run 64bit instructions on a host
> running in 32bit mode? (otherwise they'll need to be doing some kind of
> emulation)
>
>   

There's nothing magical about it.  Most likely they switch to 64-bit 
mode immediately before entering the guest, and switch back immediately 
after the guest exits.  In effect their turning the host OS into a 
hybrid 32/64 bit kernel (with the vast majority of the code remaining 
32-bits).


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Avi Kivity]

Liraz Siri wrote:
> I don't really understand the implementation VirtualBox uses to
> accomplish running 64bit VM guests on a 32bit host. Is it possible
> VirtualBox have figured out how to run 64bit instructions on a host
> running in 32bit mode? (otherwise they'll need to be doing some kind of
> emulation)
>
>   

There's nothing magical about it.  Most likely they switch to 64-bit 
mode immediately before entering the guest, and switch back immediately 
after the guest exits.  In effect their turning the host OS into a 
hybrid 32/64 bit kernel (with the vast majority of the code remaining 
32-bits).


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Avi Kivity]

Liraz Siri wrote:
> I don't really understand the implementation VirtualBox uses to
> accomplish running 64bit VM guests on a 32bit host. Is it possible
> VirtualBox have figured out how to run 64bit instructions on a host
> running in 32bit mode? (otherwise they'll need to be doing some kind of
> emulation)
>
>   

There's nothing magical about it.  Most likely they switch to 64-bit 
mode immediately before entering the guest, and switch back immediately 
after the guest exits.  In effect their turning the host OS into a 
hybrid 32/64 bit kernel (with the vast majority of the code remaining 
32-bits).


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Avi Kivity]

Jamie Lokier wrote:
> Paul Brook wrote:
>   
>> Any hardware that supports KVM is already 64-bit, and you're almost
>> entirely targetting obsolete hardware.
>>     
>
> 32-bit hardware is still in use.  My laptop is just over 2 years old,
> and there were *no* 64-bit Intel laptop CPUs available when I bought
> it (or I would have bought one).
>
> I use 32-bit KVM very often on my laptop, for OS compatibility
> testing, Windows development, BSD development, old Linux development
> and binary software packaging.
>
> (I also use QEMU, with and without KQEMU, to run older guest OSes that
> KVM does not work for.)
>
> To say 32-bit KVM-capable hardware is obsolete implies all _relevant_
> laptop users buy new ones every less than 2 years, which sounds
> ridiculous to me.
>
>   

Well, your laptop won't run 64-bit guests at native speeds.  The 
VirtualBox hack requires 64-bit capable hardware, more than likely.  It 
just allows you to run a 32-bit host OS.

If you do have 64-bit capable hardware, then nothing prevents you from 
running a 64-bit host OS (still capable of running 32-bit apps) or a 
64-bit kernel and 32-bit userspace.  The VirtualBox trick is mostly 
relevant to Windows, where 32-bit is still much more popular than 64-bit.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri]

Avi Kivity wrote:

> There's nothing magical about it.  Most likely they switch to 64-bit
> mode immediately before entering the guest, and switch back immediately
> after the guest exits.  In effect their turning the host OS into a
> hybrid 32/64 bit kernel (with the vast majority of the code remaining
> 32-bits).

Sounds easy! Why, I bet one of those KVM wizards could do that over the
weekend, being so smart and all... ;)

Pardon my ignorance, but is it possible to switch to 64-bit mode in
userspace, or do you absolutely need kernel-level support to do that?

Cheers,
Liraz

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Avi Kivity]

Liraz Siri wrote:
> Sounds easy! Why, I bet one of those KVM wizards could do that over the
> weekend, being so smart and all... ;)
>   

Sure, if we switch to 21-day weekends.

> Pardon my ignorance, but is it possible to switch to 64-bit mode in
> userspace, or do you absolutely need kernel-level support to do that?
>   

Kernel mode is absolutely required.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Frank Mehnert]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Wednesday 24 December 2008, Anthony Liguori wrote:
> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
> bunch of QEMU code and AFAIK has not shared any of their changes back
> with the QEMU community.  They are completely entitled to do this of
> course based on the licensing of QEMU.

Sorry, that is not true. We have taken several parts of Qemu and all
changes we did to the code are available on our public SVN (e.g. slirp,
recompiler, some devices).

> Some of their most interesting changes (like SATA emulation, rewritten
> USB emulation) remain available only in their closed source version.  I
> find that extremely unfortunate because that would be some of the
> easiest and most useful code to try to merge from their project.

Some of these parts might be available under GPL in the future.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert    Sun Microsystems    http://www.sun.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Stefan Weil]

Frank Mehnert schrieb:
> On Wednesday 24 December 2008, Anthony Liguori wrote:
>> Some of their most interesting changes (like SATA emulation, rewritten
>> USB emulation) remain available only in their closed source version. I
>> find that extremely unfortunate because that would be some of the
>> easiest and most useful code to try to merge from their project.
>
> Some of these parts might be available under GPL in the future.
>
> Kind regards,
>
> Frank

Remote desktop (RDP) is also an interesting part of the closed source
version.
Maybe you consider to put it under GPL, too.

Kind regards,

Stefan

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Anthony Liguori]

Frank Mehnert wrote:
> On Wednesday 24 December 2008, Anthony Liguori wrote:
>   
>> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
>> bunch of QEMU code and AFAIK has not shared any of their changes back
>> with the QEMU community.  They are completely entitled to do this of
>> course based on the licensing of QEMU.
>>     
>
> Sorry, that is not true.

As I said, sharing implies a two-way exchange.  The VirtualBox 
development was not done publicly and to the best of my knowledge, no 
attempt has been made by the VirtualBox developers to push any of their 
changes back into QEMU.  All other virtualization projects (Xen and it's 
variants, KVM, etc.) have made an attempt to push changes back to QEMU.

Yes, you have a public SVN that appeared long after your development 
started.  Are we supposed to troll through it looking for changes that 
may or may not be applicable to upstream?  It's extraordinarily 
difficult because you've made a huge number of changes to your QEMU fork 
that have nothing to do with bug fixes.

This is not how Open Source development works.  You don't make a bunch 
of changes private, put out a repo after the fact, and make no attempt 
to work with any of the projects you took the majority of your code 
from.  You can call it open all you want but it simply isn't.  We won't 
even get into the whole contributor agreement non-sense.

>> Some of their most interesting changes (like SATA emulation, rewritten
>> USB emulation) remain available only in their closed source version.  I
>> find that extremely unfortunate because that would be some of the
>> easiest and most useful code to try to merge from their project.
>>     
>
> Some of these parts might be available under GPL in the future.
>   

That would be nice but I'm not going to hold my breathe.

Regards,

Anthony Liguori

> Kind regards,
>
> Frank
>   

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Frank Mehnert]

[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]

Hi,

On Tuesday 06 January 2009, Anthony Liguori wrote:
> Frank Mehnert wrote:
> > On Wednesday 24 December 2008, Anthony Liguori wrote:
> >> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
> >> bunch of QEMU code and AFAIK has not shared any of their changes back
> >> with the QEMU community.  They are completely entitled to do this of
> >> course based on the licensing of QEMU.
> >
> > Sorry, that is not true.
>
> As I said, sharing implies a two-way exchange.  The VirtualBox
> development was not done publicly and to the best of my knowledge, no
> attempt has been made by the VirtualBox developers to push any of their
> changes back into QEMU.  All other virtualization projects (Xen and it's
> variants, KVM, etc.) have made an attempt to push changes back to QEMU.
>
> Yes, you have a public SVN that appeared long after your development
> started.  Are we supposed to troll through it looking for changes that

Our subversion repository is public since January 2007, so for more than
two years. It is true that we did internal releases before we started to
go public but I don't understand why do you complain. Note that we were
customer-driven from the beginning, unlike, for instance, Xen, which
was a community project when it started.

> may or may not be applicable to upstream?  It's extraordinarily
> difficult because you've made a huge number of changes to your QEMU fork
> that have nothing to do with bug fixes.

Believe me, it is difficult for us too, to follow the changes in Qemu.
And we use only a part of the Qemu code. As you mentioned in an earlier
post, VirtualBox and Qemu are quite different. We execute many code
inside the guest context (for performance reasons) while Qemu recompiles
the guest code in the context of the host. We depend on the Qemu code for
more rare cases where other mechanisms don't work (e.g. real mode). So
the most changes we did were adaptions to our environment.

> This is not how Open Source development works.  You don't make a bunch
> of changes private, put out a repo after the fact, and make no attempt
> to work with any of the projects you took the majority of your code
> from.  You can call it open all you want but it simply isn't.  We won't
> even get into the whole contributor agreement non-sense.
>
> >> Some of their most interesting changes (like SATA emulation, rewritten
> >> USB emulation) remain available only in their closed source version.  I
> >> find that extremely unfortunate because that would be some of the
> >> easiest and most useful code to try to merge from their project.
> >
> > Some of these parts might be available under GPL in the future.
>
> That would be nice but I'm not going to hold my breathe.

Do you really know our public SVN? The majority of the code was written
from scratch and the most interesting parts are available for public
re-use.

Btw, I'm subscribed to this list, no need to reply me directly.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert    Sun Microsystems    http://www.sun.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Blue Swirl]

On 1/6/09, Frank Mehnert <Frank.Mehnert@sun.com> wrote:
> Hi,
>
>
>  On Tuesday 06 January 2009, Anthony Liguori wrote:
>  > Frank Mehnert wrote:
>  > > On Wednesday 24 December 2008, Anthony Liguori wrote:
>  > >> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
>  > >> bunch of QEMU code and AFAIK has not shared any of their changes back
>  > >> with the QEMU community.  They are completely entitled to do this of
>  > >> course based on the licensing of QEMU.
>  > >
>  > > Sorry, that is not true.
>  >
>  > As I said, sharing implies a two-way exchange.  The VirtualBox
>  > development was not done publicly and to the best of my knowledge, no
>  > attempt has been made by the VirtualBox developers to push any of their
>  > changes back into QEMU.  All other virtualization projects (Xen and it's
>  > variants, KVM, etc.) have made an attempt to push changes back to QEMU.
>  >
>  > Yes, you have a public SVN that appeared long after your development
>  > started.  Are we supposed to troll through it looking for changes that
>
>
> Our subversion repository is public since January 2007, so for more than
>  two years. It is true that we did internal releases before we started to
>  go public but I don't understand why do you complain. Note that we were
>  customer-driven from the beginning, unlike, for instance, Xen, which
>  was a community project when it started.
>
>
>  > may or may not be applicable to upstream?  It's extraordinarily
>  > difficult because you've made a huge number of changes to your QEMU fork
>  > that have nothing to do with bug fixes.
>
>
> Believe me, it is difficult for us too, to follow the changes in Qemu.
>  And we use only a part of the Qemu code. As you mentioned in an earlier
>  post, VirtualBox and Qemu are quite different. We execute many code
>  inside the guest context (for performance reasons) while Qemu recompiles
>  the guest code in the context of the host. We depend on the Qemu code for
>  more rare cases where other mechanisms don't work (e.g. real mode). So
>  the most changes we did were adaptions to our environment.
>
>
>  > This is not how Open Source development works.  You don't make a bunch
>  > of changes private, put out a repo after the fact, and make no attempt
>  > to work with any of the projects you took the majority of your code
>  > from.  You can call it open all you want but it simply isn't.  We won't
>  > even get into the whole contributor agreement non-sense.
>  >
>  > >> Some of their most interesting changes (like SATA emulation, rewritten
>  > >> USB emulation) remain available only in their closed source version.  I
>  > >> find that extremely unfortunate because that would be some of the
>  > >> easiest and most useful code to try to merge from their project.
>  > >
>  > > Some of these parts might be available under GPL in the future.
>  >
>  > That would be nice but I'm not going to hold my breathe.
>
>
> Do you really know our public SVN? The majority of the code was written
>  from scratch and the most interesting parts are available for public
>  re-use.

I tried to merge some slirp bits once:
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html

Of course it would be much easier for all of us if someone submitted
the changes one at a time, each change described properly and patches
generated against current Qemu SVN.

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Anthony Liguori]

Frank Mehnert wrote:
> Hi,
>
> On Tuesday 06 January 2009, Anthony Liguori wrote:
>   
>
> Do you really know our public SVN? The majority of the code was written
> from scratch and the most interesting parts are available for public
> re-use.
>   

My main concern is the device model code and that code is either from 
QEMU, Bochs, of VGABIOS.  The stuff written from scratch (SATA and OHCI 
support) is not available publicly.

There's a lot of divergence and a lot of code restructuring (especially 
in the VGA code) that makes merging cherry picking stuff extremely 
difficult.  Most of the changes make no attempt to maintain consistency 
with the rest of QEMU.

If ya'll are interested in merging stuff back upstream, then I'm happy 
to work with you on it.  It seems like a huge task though and, as I've 
said, I've seen no effort or interest from Sun on this.  It's really 
unfortunate because there have been many bugs found in Xen, KVM, or QEMU 
that I've gone back and seen fixes for already in VirtualBox.  Likewise, 
there are fixes in QEMU/Xen/KVM that are not in VirtualBox.  It's a huge 
amount of wasted effort.

Regards,

Anthony Liguori

> Btw, I'm subscribed to this list, no need to reply me directly.
>
> Kind regards,
>
> Frank
>   

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Frank Mehnert]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

On Tuesday 06 January 2009, Anthony Liguori wrote:
> Frank Mehnert wrote:
> > Do you really know our public SVN? The majority of the code was written
> > from scratch and the most interesting parts are available for public
> > re-use.
>
> My main concern is the device model code and that code is either from
> QEMU, Bochs, of VGABIOS.  The stuff written from scratch (SATA and OHCI
> support) is not available publicly.

AFAIK, the following public available (VBox-OSE) device emulations and
host backends were written from scratch (this is our Devices/ directory):
 * the PIIX3/PIIX4 ATA controller (almost completely rewritten, you
   might find 5% of the code in the QEMU ATA emulation)
 * the generic block layer
 * support for access to host CD/DVD mediums inclusive SCSI command
   passthrough
 * backends for VDI, VMDK, VHD file formats
 * the PulseAudio backend
 * the Solaris audio backend
 * the ICH AC97 audio controller
 * the network sniffer (creates wireshark-compatible capture files)
 * the VM-internal network backend
 * the TAP device backend
 * the host network interface driver
 * the UART device + backends for named pipes and host ports
 * the VBox guest device

Furthermore we used QEMU code from the PCnet emulation, the VGA device,
the slirp NAT engine and more. Indeed, we had to change the code heavily
to make it fit to our needs. For instance, the PCnet emulation got a
send queue to speed up sending. And of course we execute a remarkable
part of the device emulation code in the guest context. These changes
are only examples, there are more. These changes are (in most cases) no
bug fixes but adaptions of the original code to our environment and
improvements which could not easily applied to QEMU due to the different
infrastructure.

> There's a lot of divergence and a lot of code restructuring (especially
> in the VGA code) that makes merging cherry picking stuff extremely
> difficult.  Most of the changes make no attempt to maintain consistency
> with the rest of QEMU.

As I tried to explain in the previous E-mail and above, the restructuration
was necessary due to the different requirements of VirtualBox. Please don't
blame us for adapting code to our needs.

Not to forget the different coding style. VBox has a uniform coding style
which is very different from QEMU, and this makes it more difficult to
exchange code between these projects.

> If ya'll are interested in merging stuff back upstream, then I'm happy
> to work with you on it.  It seems like a huge task though and, as I've
> said, I've seen no effort or interest from Sun on this.  It's really
> unfortunate because there have been many bugs found in Xen, KVM, or QEMU
> that I've gone back and seen fixes for already in VirtualBox.  Likewise,
> there are fixes in QEMU/Xen/KVM that are not in VirtualBox.  It's a huge
> amount of wasted effort.

Your original claim was that innotek/Sun used code from QEMU but does not
make bug fixes / improvements / code written from scratch available to QEMU.

You are right that there _is_ duplicate work. Unfortunately we don't have
enough ressources to employ people to adapt VirtualBox code to make it
work with QEMU. But nobody prevents you or other QEMU hackers to go through
our changesets and pick up bug fixes and port them back to QEMU. We do the
the same with the QEMU code to get fixes into VirtualBox (and we should do
this much more often).

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert    Sun Microsystems    http://www.sun.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Jamie Lokier]

Frank Mehnert wrote:
>  * the PIIX3/PIIX4 ATA controller (almost completely rewritten, you
>    might find 5% of the code in the QEMU ATA emulation)

PIIX4 is needed if you're importing a Microsoft Virtual PC image with
a Windows guest.  It won't boot on PIIX3 without some fiddly register
changes, due to Windows booting silliness.  QEMU uses PIIX3, making
such imports fiddly.

>  * backends for VDI, VMDK, VHD file formats

I wonder if the VHD (Virtual PC) backend is more reliable than QEMU's
VHD backend.  I've seen consistently corrupt images when QEMU reads a
VHD, whether in QEMU proper or using qemu-img to convert.

-- Jamie