Discussion:
qemu-system-i386 vs qemu-system-x86_64 ?
Michael Tokarev
2012-09-14 07:39:38 UTC
Permalink
What's the difference between the two except that the
latter adds some more instructions (actually whole new
subsytem) to the former? Why do we need -i386, what
-x86_64 does not do which does -i386?

Thanks,

/mjt
Daniel P. Berrange
2012-09-14 09:33:04 UTC
Permalink
Post by Michael Tokarev
What's the difference between the two except that the
latter adds some more instructions (actually whole new
subsytem) to the former? Why do we need -i386, what
-x86_64 does not do which does -i386?
AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host.

Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Michael Tokarev
2012-09-14 09:39:44 UTC
Permalink
Post by Daniel P. Berrange
Post by Michael Tokarev
What's the difference between the two except that the
latter adds some more instructions (actually whole new
subsytem) to the former? Why do we need -i386, what
-x86_64 does not do which does -i386?
AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host.
Isn't it the other way around?

Or, does qemu-system-i386 EVER support kvm?

Thanks,

/mjt
Jan Kiszka
2012-09-14 10:00:39 UTC
Permalink
Post by Michael Tokarev
Post by Daniel P. Berrange
Post by Michael Tokarev
What's the difference between the two except that the
latter adds some more instructions (actually whole new
subsytem) to the former? Why do we need -i386, what
-x86_64 does not do which does -i386?
AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host.
Isn't it the other way around?
Or, does qemu-system-i386 EVER support kvm?
It does support KVM on 32-bit (minus undiscovered bugs in 32-bit-only
kernel code paths once in a while - none known right now, though). Don't
confuse old qemu-kvm with QEMU here. The latter always supported KVM
with both variants, and qemu-kvm now also does as it stopped being
different.

The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).

Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
Michael Tokarev
2012-09-14 10:03:58 UTC
Permalink
On 14.09.2012 14:00, Jan Kiszka wrote:
[]
Post by Jan Kiszka
The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).
Interesting. Maybe someone should look at the difference on TCG side
and merge interesting bits from i386 to x86_64... :)

The thing is: x86_64 becomes the only x86 platform these days, or at
least the MAIN platform.

Thank you for the clarification -- very useful information indeed!

/mjt
Jan Kiszka
2012-09-14 10:12:43 UTC
Permalink
Post by Michael Tokarev
[]
Post by Jan Kiszka
The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).
Interesting. Maybe someone should look at the difference on TCG side
and merge interesting bits from i386 to x86_64... :)
I suppose the difference - for our use cases at least - lies in the
different register and address sizes. Maybe there is room for more
runtime optimizations, we never looked in that details as -i386 still
works fine. And, if you are on 32-bit host (see below) - but we aren't,
qemu-system-x86_64 hurts even more.
Post by Michael Tokarev
The thing is: x86_64 becomes the only x86 platform these days, or at
least the MAIN platform.
I know, and I'm telling everyone. Still, too many crazy people keep on
installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will
improve this.
Post by Michael Tokarev
Thank you for the clarification -- very useful information indeed!
/mjt
You are welcome.

Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
Daniel P. Berrange
2012-09-14 10:20:44 UTC
Permalink
Post by Jan Kiszka
Post by Michael Tokarev
[]
Post by Jan Kiszka
The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).
Interesting. Maybe someone should look at the difference on TCG side
and merge interesting bits from i386 to x86_64... :)
I suppose the difference - for our use cases at least - lies in the
different register and address sizes. Maybe there is room for more
runtime optimizations, we never looked in that details as -i386 still
works fine. And, if you are on 32-bit host (see below) - but we aren't,
qemu-system-x86_64 hurts even more.
Post by Michael Tokarev
The thing is: x86_64 becomes the only x86 platform these days, or at
least the MAIN platform.
I know, and I'm telling everyone. Still, too many crazy people keep on
installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will
improve this.
It is quite depressing that 32-bit still accounts for 55% of deployed
Fedora installs:

http://smolt.fedoraproject.org/static/stats/stats.html

That said, a year ago it was even worse with 32-bit up in 70% region


Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Jan Kiszka
2012-09-14 10:32:17 UTC
Permalink
Post by Daniel P. Berrange
Post by Jan Kiszka
Post by Michael Tokarev
[]
Post by Jan Kiszka
The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).
Interesting. Maybe someone should look at the difference on TCG side
and merge interesting bits from i386 to x86_64... :)
I suppose the difference - for our use cases at least - lies in the
different register and address sizes. Maybe there is room for more
runtime optimizations, we never looked in that details as -i386 still
works fine. And, if you are on 32-bit host (see below) - but we aren't,
qemu-system-x86_64 hurts even more.
Post by Michael Tokarev
The thing is: x86_64 becomes the only x86 platform these days, or at
least the MAIN platform.
I know, and I'm telling everyone. Still, too many crazy people keep on
installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will
improve this.
It is quite depressing that 32-bit still accounts for 55% of deployed
http://smolt.fedoraproject.org/static/stats/stats.html
That said, a year ago it was even worse with 32-bit up in 70% region
There is a nice comment by Steven that I pinned on my wall, the last
paragraph text-marked:
http://lkml.indiana.edu/hypermail/linux/kernel/1206.1/00445.html. These
days, I prefer to just point people to that printout instead of arguing.
Didn't help yet, unfortunately, to convince our corporate VPN vendor to
finally support 64-bit with his proprietary clients. Maybe because they
didn't visit my office yet.

The problem is also that some distros default the download to 32-bit
when asking for a desktop, e.g. Ubuntu or OpenSUSE. Kudos to Fedora for
not doing this.

Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
Peter Maydell
2012-09-14 10:39:12 UTC
Permalink
Post by Jan Kiszka
Post by Michael Tokarev
The thing is: x86_64 becomes the only x86 platform these days, or at
least the MAIN platform.
I know, and I'm telling everyone. Still, too many crazy people keep on
installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will
improve this.
Personally I'm waiting for my distro to support seamless upgrade
from 32 bit to 64 bit. With a little luck multiarch should make
this possible in a reasonably clean way...

-- PMM
Aurelien Jarno
2012-09-14 12:24:57 UTC
Permalink
Post by Michael Tokarev
[]
Post by Jan Kiszka
The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on
the TCG side: We measured noticeable performance benefits when running
32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I
don't have numbers at hand, but colleagues decided to use the 32-bit
version for that reason (when no KVM is available).
Interesting. Maybe someone should look at the difference on TCG side
and merge interesting bits from i386 to x86_64... :)
Most of the code between i386 and x86_64 is basically the same. For
improving TCG performances, the only interesting thing to merge from i386 to
x86_64 would be the use 32-bit registers instead of 64-bit registers. Oh
wait...
--
Aurelien Jarno GPG: 1024D/F1BCDB73
***@aurel32.net http://www.aurel32.net
Blue Swirl
2012-09-14 19:29:13 UTC
Permalink
Post by Michael Tokarev
What's the difference between the two except that the
latter adds some more instructions (actually whole new
subsytem) to the former? Why do we need -i386, what
-x86_64 does not do which does -i386?
i386 should not allow executing x86_64 code or using other 64 bit
features but raise exceptions. 64 bit CPU models should not be
available to i386 emulator. Physical memory is limited to PAE maximum
for i386.

We could also let x86_64 diverge from i386 and remove legacy devices
to emulate a modern legacy free system while keeping i386 closer to
1990s machines, though this would be mainly a linkage issue.
Post by Michael Tokarev
Thanks,
/mjt
Loading...