[Qemu-devel] Which qemu ports actually work?

[Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

I am not sure this inquiry is appropriate for this mailing list.  But at
the qemu web site, this is the only mailing list mentioned.

I would like to run as many OS's as possible under as many processors as
possible, using qemu.  Results thus far has not been very encouraging,
though.

Here is my test matrix:

         fbsd-8_1       nbsd-5_0_2    debian-5      gentoo        hurd

sparc      n/a          OK            n/a           n/a           n/a

sparc64    fw crash     fw crash      kern crash    black fb      n/a

ppc        early hang   fw crash      OK            kern hang     n/a

ppc64      early panic  fw crash      kern hang     kern hang     n/a

i386       OK           OK            OK                          installs,
                                                                  non-booting
x86_64     OK           OK            OK

These are results from multiple attempts and google searches for what
other people have done.  Unfortunately, there aren't many matches,
except that the various error messages I get have been experienced by
several other people.

Is this what I can expect from qemu today?  Are the goals of the qemu
project to make the various ports operational for running these OS's?
If yes, what is the time frame?

It would be nice with a status page (there is a blank such page already,
I mean a non-blank page...) informing about the status of the various
ports.  A naive user--such as myself--tends to assume that a released
port actually works.  It takes many hours of poorly used effort before
one can conclude that e.g., sparc64 does not work at all.

(We should probably not blame qemu for hurd's shortcomings here.  Hurd
is highly experimental.  I have not tried it on actual hardware.)

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 26.10.2010, at 09:38, Torbjorn Granlund wrote:

> I am not sure this inquiry is appropriate for this mailing list.  But at
> the qemu web site, this is the only mailing list mentioned.
> 
> I would like to run as many OS's as possible under as many processors as
> possible, using qemu.  Results thus far has not been very encouraging,
> though.
> 
> Here is my test matrix:
> 
>         fbsd-8_1       nbsd-5_0_2    debian-5      gentoo        hurd
> 
> sparc      n/a          OK            n/a           n/a           n/a
> 
> sparc64    fw crash     fw crash      kern crash    black fb      n/a
> 
> ppc        early hang   fw crash      OK            kern hang     n/a
> 
> ppc64      early panic  fw crash      kern hang     kern hang     n/a

Where exactly do the Linux kernels hang here? For BSD, I don't know. If there are patches flowing in to fix BSD support, I'll gladly review and take them, but I won't proactively try to get it running.

> 
> i386       OK           OK            OK                          installs,
>                                                                  non-booting
> x86_64     OK           OK            OK
> 
> These are results from multiple attempts and google searches for what
> other people have done.  Unfortunately, there aren't many matches,
> except that the various error messages I get have been experienced by
> several other people.
> 
> Is this what I can expect from qemu today?  Are the goals of the qemu
> project to make the various ports operational for running these OS's?
> If yes, what is the time frame?
> 
> It would be nice with a status page (there is a blank such page already,
> I mean a non-blank page...) informing about the status of the various
> ports.  A naive user--such as myself--tends to assume that a released
> port actually works.  It takes many hours of poorly used effort before
> one can conclude that e.g., sparc64 does not work at all.

Well, the good news on this part is that the qemu web page is a wiki! So if there's no status in there at all, feel free to add your experience. Natalia also has a page trying to list compatibility.


Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Alexander Graf <agraf@suse.de> writes:

  Where exactly do the Linux kernels hang here? For BSD, I don't
  know. If there are patches flowing in to fix BSD support, I'll gladly
  review and take them, but I won't proactively try to get it running.

Is this how most qemu hackers feel, in effect that qemu is a hardware
emulator for the kernel linux?  To me, that seem like aiming low, and also
a strategy resulting in a less robust program.  (I maintain a couple of
free software packages, and I certainly run as many tests as possible to
make them robust.)

(1) For ppc32, gentoo hans quickly, the last line is this:

    Memory: 247644k/262144k avalable (5652k kernel code, 14500l reserved, 212k data, 137k  bss, 260k ini

    This last line is long, it is truncated to the right.


(2) For ppc64, the last lines are:

    Calling quiesce ...
    returning from prom_init

    This happens is almost immediately, within a second.

    (Debian and Gentoo hangs at the same positions.)


(3) The sparc64 crash for Debian happens much later.  The last lines are:

    /bin/sh: relocation error: /bin/sh: symbol eaitpid, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
    [   48.xxxxxx] Kernel panic - not syncing: Attempted to kill init!
    [   48.xxxxxx] Press Stop-A (L1-A) to return to the boot prom


I am not sure gentoo should be expected to work, at least not the 64-bit
kernel.  It claims to be "G5" whatever that means (G5 is Apple's name for
the IBM ppc970 processor, not a particular computer architecture, so I am
not sure what gentoo means).

  Well, the good news on this part is that the qemu web page is a wiki! So
  if there's no status in there at all, feel free to add your experience.
  Natalia also has a page trying to list compatibility.

Do you have a pointer to that page of this Natalia?

BTW, this is the qemu version I am trying:

king$ qemu --version
QEMU emulator version 0.13.0, Copyright (c) 2003-2008 Fabrice Bellard

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 26.10.2010, at 12:02, Torbjorn Granlund <tg@gmplib.org> wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>  Where exactly do the Linux kernels hang here? For BSD, I don't
>  know. If there are patches flowing in to fix BSD support, I'll gladly
>  review and take them, but I won't proactively try to get it running.
> 
> Is this how most qemu hackers feel, in effect that qemu is a hardware
> emulator for the kernel linux?  To me, that seem like aiming low, and also
> a strategy resulting in a less robust program.  (I maintain a couple of
> free software packages, and I certainly run as many tests as possible to
> make them robust.)

No, it's a matter of time. If you could make the day have 40 hours, I'll gladly look into BSD :). Keep in mind that qemu is open source, written mostly by volunteers.

> 
> (1) For ppc32, gentoo hans quickly, the last line is this:
> 
>    Memory: 247644k/262144k avalable (5652k kernel code, 14500l reserved, 212k data, 137k  bss, 260k ini
> 
>    This last line is long, it is truncated to the right.

Hrm. Please send me the vmlinux.gz file in a private mail.

> 
> 
> (2) For ppc64, the last lines are:
> 
>    Calling quiesce ...
>    returning from prom_init
> 
>    This happens is almost immediately, within a second.
> 
>    (Debian and Gentoo hangs at the same positions.)

This probably means that the bootloader chose to boot a ppc32 kernel on ppc64. Please try booting vmlinux and initrd directly using -kernel and -initrd.

> (3) The sparc64 crash for Debian happens much later.  The last lines are:
> 
>    /bin/sh: relocation error: /bin/sh: symbol eaitpid, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
>    [   48.xxxxxx] Kernel panic - not syncing: Attempted to kill init!
>    [   48.xxxxxx] Press Stop-A (L1-A) to return to the boot prom

I don't know much about the status of sparc64, sorry.

> 
> 
> I am not sure gentoo should be expected to work, at least not the 64-bit
> kernel.  It claims to be "G5" whatever that means (G5 is Apple's name for
> the IBM ppc970 processor, not a particular computer architecture, so I am
> not sure what gentoo means).

Qemu emulates a mac, so it should be fine.

> 
>  Well, the good news on this part is that the qemu web page is a wiki! So
>  if there's no status in there at all, feel free to add your experience.
>  Natalia also has a page trying to list compatibility.
> 
> Do you have a pointer to that page of this Natalia?

I'm typing from a phone right now. Google should know. Just search for qemu os list or so.

> 
> BTW, this is the qemu version I am trying:
> 
> king$ qemu --version
> QEMU emulator version 0.13.0, Copyright (c) 2003-2008 Fabrice Bellard

Please make sure to also try the latest git version. I doubt it helps on the ppc side, but sparc might benefit from it.

> 

Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Alexander Graf <agraf@suse.de> writes:

  > (1) For ppc32, gentoo hans quickly, the last line is this:
  > 
  >    Memory: 247644k/262144k avalable (5652k kernel code, 14500l reserved, 212k data, 137k  bss, 260k ini
  > 
  >    This last line is long, it is truncated to the right.
  
  Hrm. Please send me the vmlinux.gz file in a private mail.
  
Perhaps it is easier to download the image I used:
ftp://ftp.sunet.se/pub/Linux/distributions/gentoo/releases/ppc/current-iso/install-powerpc-minimal-20101017.iso

(This machine has a 10 Gbps Internet connection, but perhaps you have
better connectivity to another Gentoo mirror.)

  > (2) For ppc64, the last lines are:
  > 
  >    Calling quiesce ...
  >    returning from prom_init
  > 
  >    (Debian and Gentoo hangs at the same positions.)
  
  This probably means that the bootloader chose to boot a ppc32 kernel
  on ppc64. Please try booting vmlinux and initrd directly using -kernel
  and -initrd.
  
Hmm.  For Gentoo, I explicitly tried the "G5" and "ppc32" boot
alternatives.

For Debian, I used "install".  Now I tried the better choice
"install64", which comes a bit longer.  It fails in a new way: it
ignores keyboard input, This happens after the kernel has booted, and
the installer has started.

I tried this, e.g.:

qemu-system-ppc64 -vnc :1 -hda new.img -cdrom /jails/shell/u/GNU/Debian/iso/debian-506-powerpc-CD-1.iso -boot d -net nic,macaddr=52:54:00:12:34:59,model=e1000 -net tap,ifname=tap3,script=no -m 512

(I also tried without -vnc, and  with less memory.  Same, same.)

  > king$ qemu --version
  > QEMU emulator version 0.13.0, Copyright (c) 2003-2008 Fabrice Bellard
  
  Please make sure to also try the latest git version. I doubt it helps
  on the ppc side, but sparc might benefit from it.

I think this will have to wait.

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 26.10.2010, at 12:52, Torbjorn Granlund wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> (1) For ppc32, gentoo hans quickly, the last line is this:
>> 
>>   Memory: 247644k/262144k avalable (5652k kernel code, 14500l reserved, 212k data, 137k  bss, 260k ini
>> 
>>   This last line is long, it is truncated to the right.
> 
>  Hrm. Please send me the vmlinux.gz file in a private mail.
> 
> Perhaps it is easier to download the image I used:
> ftp://ftp.sunet.se/pub/Linux/distributions/gentoo/releases/ppc/current-iso/install-powerpc-minimal-20101017.iso
> 
> (This machine has a 10 Gbps Internet connection, but perhaps you have
> better connectivity to another Gentoo mirror.)

k, I'll give it a try soon.

> 
>> (2) For ppc64, the last lines are:
>> 
>>   Calling quiesce ...
>>   returning from prom_init
>> 
>>   (Debian and Gentoo hangs at the same positions.)
> 
>  This probably means that the bootloader chose to boot a ppc32 kernel
>  on ppc64. Please try booting vmlinux and initrd directly using -kernel
>  and -initrd.
> 
> Hmm.  For Gentoo, I explicitly tried the "G5" and "ppc32" boot
> alternatives.
> 
> For Debian, I used "install".  Now I tried the better choice
> "install64", which comes a bit longer.  It fails in a new way: it
> ignores keyboard input, This happens after the kernel has booted, and
> the installer has started.

Yes, ignoring keyboard input sounds right. The issue here is that we're basically emulating a PPC32 machine, but plug in a PPC64 CPU. This works mostly, but for ADB it breaks, as the guest kernel doesn't have support for our ADB controller. Unfortunately, keyboard and mouse are attached using ADB.

One way to get around this is to use -usb -usbdevice keyboard. Another way is to use the serial port instead of graphical console.

> I tried this, e.g.:
> 
> qemu-system-ppc64 -vnc :1 -hda new.img -cdrom /jails/shell/u/GNU/Debian/iso/debian-506-powerpc-CD-1.iso -boot d -net nic,macaddr=52:54:00:12:34:59,model=e1000 -net tap,ifname=tap3,script=no -m 512
> 
> (I also tried without -vnc, and  with less memory.  Same, same.)

See above, the issue is well known. Andreas is currently working on a CHRP target which should get rid of those limitations. But those efforts only just begun.

Please also keep in mind that PPC emulation is _very_ slow. If you need performance for this, please just grab a PPC machine and use KVM on it. It will be a lot faster.


Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

  > "install64", which comes a bit longer.  It fails in a new way: it
  > ignores keyboard input, This happens after the kernel has booted, and
  > the installer has started.
  
  Yes, ignoring keyboard input sounds right. The issue here is that
  we're basically emulating a PPC32 machine, but plug in a PPC64
  CPU. This works mostly, but for ADB it breaks, as the guest kernel
  doesn't have support for our ADB controller. Unfortunately, keyboard
  and mouse are attached using ADB.
  
  One way to get around this is to use -usb -usbdevice keyboard.

That makes no difference.  I suppose it is still using the adb keyboard.

  Another way is to use the serial port instead of graphical console.
  
I cannot get this to work either.

With -nographic I get the same lock as initially, after

  Device tree strings 0x0000000002450000 -> 0x00000000024504d9
  Device tree struct  0x0000000002451000 -> 0x0000000002453000
  Calling quiesce ...
  returning from prom_init

it hangs.

  Please also keep in mind that PPC emulation is _very_ slow.

Why is it slow?

  If you need performance for this, please just grab a PPC machine and
  use KVM on it. It will be a lot faster.

Physical machines take space and need power.  Qemu is a lot leaner.  :-)

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 27.10.2010, at 01:39, Torbjorn Granlund wrote:

>> "install64", which comes a bit longer.  It fails in a new way: it
>> ignores keyboard input, This happens after the kernel has booted, and
>> the installer has started.
> 
>  Yes, ignoring keyboard input sounds right. The issue here is that
>  we're basically emulating a PPC32 machine, but plug in a PPC64
>  CPU. This works mostly, but for ADB it breaks, as the guest kernel
>  doesn't have support for our ADB controller. Unfortunately, keyboard
>  and mouse are attached using ADB.
> 
>  One way to get around this is to use -usb -usbdevice keyboard.
> 
> That makes no difference.  I suppose it is still using the adb keyboard.
> 
>  Another way is to use the serial port instead of graphical console.
> 
> I cannot get this to work either.
> 
> With -nographic I get the same lock as initially, after
> 
>  Device tree strings 0x0000000002450000 -> 0x00000000024504d9
>  Device tree struct  0x0000000002451000 -> 0x0000000002453000
>  Calling quiesce ...
>  returning from prom_init
> 
> it hangs.

It doesn't hang. It tries to display stuff on the graphical screen which you disabled. You need to tell the kernel to use the serial console.

> 
>  Please also keep in mind that PPC emulation is _very_ slow.
> 
> Why is it slow?

Because we're flushing the TLB on almost every MMU opcode.

> 
>  If you need performance for this, please just grab a PPC machine and
>  use KVM on it. It will be a lot faster.
> 
> Physical machines take space and need power.  Qemu is a lot leaner.  :-)

*shrug* depends on what you want to do. If you want to actually do something useful, I'd recommend KVM.


Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Alexander Graf <agraf@suse.de> writes:

  >  Device tree strings 0x0000000002450000 -> 0x00000000024504d9
  >  Device tree struct  0x0000000002451000 -> 0x0000000002453000
  >  Calling quiesce ...
  >  returning from prom_init
  > 
  > it hangs.
  
  It doesn't hang. It tries to display stuff on the graphical screen
  which you disabled. You need to tell the kernel to use the serial
  console.
  
I take it back and say "it appears to hang to a naive user".

I suppose I'll wait until I can find some documentation, such as a
simple example from which to start, and stop DOSing your developers'
mailing list with my qemu troubles.  :-)

  >  If you need performance for this, please just grab a PPC machine and
  >  use KVM on it. It will be a lot faster.
  > 
  > Physical machines take space and need power.  Qemu is a lot leaner.  :-)
  
  *shrug* depends on what you want to do. If you want to actually do
  *something useful, I'd recommend KVM.

You might have different goals than me.  Speed is nice, and sometimes
critically important.  But for my project to get (pseudo) access to lots
of more hardware for GNU software testing purposes, speed is not a major
issue.  Stability, robustness, reproducibility, documentation, are
critically important to me.

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 27.10.2010, at 02:21, Torbjorn Granlund wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> Device tree strings 0x0000000002450000 -> 0x00000000024504d9
>> Device tree struct  0x0000000002451000 -> 0x0000000002453000
>> Calling quiesce ...
>> returning from prom_init
>> 
>> it hangs.
> 
>  It doesn't hang. It tries to display stuff on the graphical screen
>  which you disabled. You need to tell the kernel to use the serial
>  console.
> 
> I take it back and say "it appears to hang to a naive user".
> 
> I suppose I'll wait until I can find some documentation, such as a
> simple example from which to start, and stop DOSing your developers'
> mailing list with my qemu troubles.  :-)

Sounds great :). Please keep in mind that if you're running into these issues, others might too. And if you find something out and miss documentation, please create some. That's why we made everything be a wiki these days :).

> 
>> If you need performance for this, please just grab a PPC machine and
>> use KVM on it. It will be a lot faster.
>> 
>> Physical machines take space and need power.  Qemu is a lot leaner.  :-)
> 
>  *shrug* depends on what you want to do. If you want to actually do
>  *something useful, I'd recommend KVM.
> 
> You might have different goals than me.  Speed is nice, and sometimes
> critically important.  But for my project to get (pseudo) access to lots
> of more hardware for GNU software testing purposes, speed is not a major
> issue.  Stability, robustness, reproducibility, documentation, are
> critically important to me.

Yes, stability and robustness clearly speak for KVM too ;). I wouldn't trust the PPC emulation to a full extent and in fact, even the others might be buggy at times. The best guarantee for full ISA compliance is a real CPU.

Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Alexander Graf <agraf@suse.de> writes:

  Sounds great :). Please keep in mind that if you're running into these
  issues, others might too. And if you find something out and miss
  documentation, please create some. That's why we made everything be a
  wiki these days :).

If I get a meaningful number of OS/qemu combinations to actually work, I
intend to put someting together.  I am far from there yet.  What I would
write is a simple list of commands to get *something* to work for each
tuple.

I have limited time trying to reverse engineer how things are intended
to work, how to switch this and that off via qemu.  It is usually more
efficient that developers write at least rudimentary documentation.
  
I live in this word myself, I have contributed to the GNU project since
the early 1990'ies.  I am not asking volunteers to "work harder".  But
writing great software and then make it very, very hard to use by not
spending 1% of ones time writing documentation, is poor use of the
volunteer time!

-- 
Torbjörn

[Qemu-devel] Re: Which qemu ports actually work?

[Paolo Bonzini]

On 10/27/2010 11:21 AM, Torbjorn Granlund wrote:
> You might have different goals than me.  Speed is nice, and sometimes
> critically important.  But for my project to get (pseudo) access to lots
> of more hardware for GNU software testing purposes, speed is not a major
> issue.  Stability, robustness, reproducibility, documentation, are
> critically important to me.

Lobbying a Debian developer into giving access to Debian porter machines 
is probably even more effective than KVM.

Paolo

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Alexander Graf <agraf@suse.de> writes:

  >  Please also keep in mind that PPC emulation is _very_ slow.
  > 
  > Why is it slow?
  
  Because we're flushing the TLB on almost every MMU opcode.

OK.  Does that mean the TLB never gets more than a single entry?
(I mean, do you flush the TLB before inserting a new entry into it?)

What is the reason for this flushing?

A related thing, related to cross endianess: I wrote a simulator many
years ago (around 1990) that turned memory "upside down" for cross
endianess.  I.e., a reference to address x was simulated as
*(memend-opsize-x), where memend points to the end of the area
simulating memory, opsize of the size in bytes of the operation.

The point of this is that one can use full-size native load or store
instructions, instead of many byte operations and shifts.

I never published this idea, but I assume it has been rediscovered and
is now a standard trick?

[Alex, excuse the duplicate, this message was bounced by nongnu.org's
MTA for bogus reasons.  It never appeared on the list.]

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Alexander Graf]

On 28.10.2010, at 01:32, Torbjorn Granlund wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> Please also keep in mind that PPC emulation is _very_ slow.
>> 
>> Why is it slow?
> 
>  Because we're flushing the TLB on almost every MMU opcode.
> 
> OK.  Does that mean the TLB never gets more than a single entry?
> (I mean, do you flush the TLB before inserting a new entry into it?)
> 
> What is the reason for this flushing?

The PPC MMU works by translating an ea -> va -> ra. The qemu soft-tlb only knows about ea -> ra mappings. So while on real hardware, we can keep several contexts in the tlb, in qemu we flush it several times on every context switch. Basically every time the ea -> va mapping gets changed.

For details on how the PPC MMU works, please check my video on the KVM Forum 2010 page.

Somehow we also end up flushing the translated code a lot, but I'll have to check the source to see why. It's probably related.

> 
> A related thing, related to cross endianess: I wrote a simulator many
> years ago (around 1990) that turned memory "upside down" for cross
> endianess.  I.e., a reference to address x was simulated as
> *(memend-opsize-x), where memend points to the end of the area
> simulating memory, opsize of the size in bytes of the operation.
> 
> The point of this is that one can use full-size native load or store
> instructions, instead of many byte operations and shifts.
> 
> I never published this idea, but I assume it has been rediscovered and
> is now a standard trick?

Endianness is not the issue really :). The MMU gives us way harder hits.


Alex

Re: [Qemu-devel] Which qemu ports actually work?

[Blue Swirl]

On Wed, Oct 27, 2010 at 8:39 AM, Torbjorn Granlund <tg@gmplib.org> wrote:
>  > "install64", which comes a bit longer.  It fails in a new way: it
>  > ignores keyboard input, This happens after the kernel has booted, and
>  > the installer has started.
>
>  Yes, ignoring keyboard input sounds right. The issue here is that
>  we're basically emulating a PPC32 machine, but plug in a PPC64
>  CPU. This works mostly, but for ADB it breaks, as the guest kernel
>  doesn't have support for our ADB controller. Unfortunately, keyboard
>  and mouse are attached using ADB.
>
>  One way to get around this is to use -usb -usbdevice keyboard.
>
> That makes no difference.  I suppose it is still using the adb keyboard.

I got to livecd prompt, with working keyboard using the following command line:
qemu-system-ppc64 -boot d -cdrom install-powerpc-minimal-2008.0.iso
-cpu 970fx -M mac99 -usb -usbdevice keyboard

At boot prompt, I just hit enter to select a G5 kernel.

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Blue Swirl <blauwirbel@gmail.com> writes:

  On Wed, Oct 27, 2010 at 8:39 AM, Torbjorn Granlund <tg@gmplib.org> wrote:
  >  > "install64", which comes a bit longer.  It fails in a new way: it
  >  > ignores keyboard input, This happens after the kernel has booted, and
  >  > the installer has started.
  >
  >  Yes, ignoring keyboard input sounds right. The issue here is that
  >  we're basically emulating a PPC32 machine, but plug in a PPC64
  >  CPU. This works mostly, but for ADB it breaks, as the guest kernel
  >  doesn't have support for our ADB controller. Unfortunately, keyboard
  >  and mouse are attached using ADB.
  >
  >  One way to get around this is to use -usb -usbdevice keyboard.
  >
  > That makes no difference.  I suppose it is still using the adb keyboard.
  
  I got to livecd prompt, with working keyboard using the following command line:
  qemu-system-ppc64 -boot d -cdrom install-powerpc-minimal-2008.0.iso
  -cpu 970fx -M mac99 -usb -usbdevice keyboard
  
  At boot prompt, I just hit enter to select a G5 kernel.
  
Wow, it indeed works!  Later Gentoo releases fail in a way similar to
Debian (an early hang).  Did you fight your way through the contorted
Gentoo install in order to see if you get a bootable system?  (I'll try
that when I have time.)

The default nic cannot be used, -net nic,model=e1000 is needed.

I started a page that intends to save others from the trouble I have.
It is at <http://gmplib.org/~tege/qemu.html>.  I'll try and collect
enough info for getting started, or save others from wasting time on
things that do not work.

[qemu-devel@nongnu.org might block this message.  It lastly tried to
pseudo-mail back using an incorrect address, then reject my messages
with a 550 code.  Some anti-spam mechanism gone bad.]

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Artyom Tarasenko]

On Thu, Oct 28, 2010 at 12:39 AM, Torbjorn Granlund <tg@gmplib.org> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
> I started a page that intends to save others from the trouble I have.
> It is at <http://gmplib.org/~tege/qemu.html>.  I'll try and collect
> enough info for getting started, or save others from wasting time on
> things that do not work.

Nice. Btw, there is no OpenSolaris version for sparc. Only for i386,
x86-64 and sparc64.

"openbsd/sparc hangs" - can you be more specific? It used to work.

Also, why would you like to start from scratch and not use Natalia's database?

http://www.claunia.com/qemu

It has some more dimensions: qemu version, OS version (in your case
some versions can be derived from the image names, but not
everywhere). Also a lot of reporters described quite precise what
didn't work, and the workarounds they performed. Screenshots of exotic
systems are nice too.

Or is the idea to have an agile matrix describing what currently works
in the git master version? Then a hash describing the used id would be
nice.


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Artyom Tarasenko <atar4qemu@gmail.com> writes:

  Nice. Btw, there is no OpenSolaris version for sparc. Only for i386,
  x86-64 and sparc64.

Fixed, thanks.

  "openbsd/sparc hangs" - can you be more specific? It used to work.
  
Some description of failues is in the plan.

  Also, why would you like to start from scratch and not use Natalia's database?
  
  http://www.claunia.com/qemu
  
I found nice graphics, and claims that some oddball and/or obsolete
operating systems (don't take my use of the term "operating system" here
as a praise for DOS, I know the proper term is "boot monitor").  I
cannot find any instructions how to reproduce any of these results.  But
perhaps useful information is hidden behind some pretty graphics
somewhere?  I didn't find any information on current systems.

  Or is the idea to have an agile matrix describing what currently works
  in the git master version? Then a hash describing the used id would be
  nice.

I am simply trying to save time for people like me that are interested
in currently used systems and cannot afford to purchase dozens of
systems.

It is tempting to make something more automatic, and test the repo, but
I am supposed to get some research done, and in a different area than
this, so I will try to resist the temptation of getting too involved
with this fun project.  :-)

-- 
Torbjörn

Re: [Qemu-devel] Which qemu ports actually work?

[Artyom Tarasenko]

>  http://www.claunia.com/qemu
>
> I found nice graphics, and claims that some oddball and/or obsolete
> operating systems (don't take my use of the term "operating system" here
> as a praise for DOS, I know the proper term is "boot monitor").  I
> cannot find any instructions how to reproduce any of these results.  But
> perhaps useful information is hidden behind some pretty graphics
> somewhere?

No, I meant reports like
http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=225
or
http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=230

Now I see that the most reports are not that detailed.

> I didn't find any information on current systems.

This is unfortunately true. Still it would be nice to have all the
infos consolidated in one database to be able to pick the best qemu
and guest versions.

> I am simply trying to save time for people like me that are interested
> in currently used systems and cannot afford to purchase dozens of
> systems.

Can imagine that some OSes might work better with alternative BIOSes.
Like Solaris:

http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html

> It is tempting to make something more automatic, and test the repo, but
> I am supposed to get some research done, and in a different area than
> this, so I will try to resist the temptation of getting too involved
> with this fun project.  :-)

That's understandable. :)

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: Which qemu ports actually work?

[Paolo Bonzini]

On 10/26/2010 09:02 PM, Torbjorn Granlund wrote:
> Do you have a pointer to that page of this Natalia?

http://www.claunia.com/qemu/old/index.php

Paolo

Re: [Qemu-devel] Re: Which qemu ports actually work?

[Stefan Weil]

Am 26.10.2010 21:34, schrieb Paolo Bonzini:
> On 10/26/2010 09:02 PM, Torbjorn Granlund wrote:
>> Do you have a pointer to that page of this Natalia?
>
> http://www.claunia.com/qemu/old/index.php
>
> Paolo
>
>

Or the new page http://www.claunia.com/qemu/.
Any user can add his/her test results there.

Stefan

Re: [Qemu-devel] Which qemu ports actually work?

[Stefan Weil]

Am 26.10.2010 18:38, schrieb Torbjorn Granlund:
> I am not sure this inquiry is appropriate for this mailing list. But at
> the qemu web site, this is the only mailing list mentioned.
>
> I would like to run as many OS's as possible under as many processors as
> possible, using qemu. Results thus far has not been very encouraging,
> though.
>
> Here is my test matrix:
>
> fbsd-8_1 nbsd-5_0_2 debian-5 gentoo hurd
>
> sparc n/a OK n/a n/a n/a
>
> sparc64 fw crash fw crash kern crash black fb n/a
>
> ppc early hang fw crash OK kern hang n/a
>
> ppc64 early panic fw crash kern hang kern hang n/a
>
> i386 OK OK OK installs,
> non-booting
> x86_64 OK OK OK
>
> These are results from multiple attempts and google searches for what
> other people have done. Unfortunately, there aren't many matches,
> except that the various error messages I get have been experienced by
> several other people.
>
> Is this what I can expect from qemu today? Are the goals of the qemu
> project to make the various ports operational for running these OS's?
> If yes, what is the time frame?
>
> It would be nice with a status page (there is a blank such page already,
> I mean a non-blank page...) informing about the status of the various
> ports. A naive user--such as myself--tends to assume that a released
> port actually works. It takes many hours of poorly used effort before
> one can conclude that e.g., sparc64 does not work at all.
>
> (We should probably not blame qemu for hurd's shortcomings here. Hurd
> is highly experimental. I have not tried it on actual hardware.)


Which kind of host did you use? i386? x86_64? Linux? Windows?

My working setups run on a Debian Linux (x86_64) host
(most were also tested sucessfully on a Debian Linux (i386) host).

Debian Linux i386, x86_64, arm, mips, mips64, ppc guests work.
Obviously many developers use similar setups, so
they are well tested and debugged.

Regards,
Stefan Weil

Re: [Qemu-devel] Which qemu ports actually work?

[Torbjorn Granlund]

Stefan Weil <weil@mail.berlios.de> writes:

  Which kind of host did you use? i386? x86_64? Linux? Windows?
  
FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).

I use the kqemu kernel module.  All software (kernel, /usr/ports) are
up-to-date as of yesterday.

  My working setups run on a Debian Linux (x86_64) host
  (most were also tested sucessfully on a Debian Linux (i386) host).
  
It would be useful if somebody published the tricks they use to get an
OS to run.  "It works for me" might make people do more trial-and-error,
but it might not make them lucky.

  Debian Linux i386, x86_64, arm, mips, mips64, ppc guests work.

I haven't tried arm and made just one futile attempt with mips (mips
wants a bios file I have yet to locate).

Are you willing to share your setups with me?  Even better, publish them
in such a way that people will easily find them?  Now, google seems
better at finding how qemu fails than how it succeeds...

  Obviously many developers use similar setups, so they are well tested
  and debugged.
  
I am glad to hear this!  

-- 
Torbjörn

[Qemu-devel] Re: Which qemu ports actually work?

[Paolo Bonzini]

On 10/26/2010 09:12 PM, Torbjorn Granlund wrote:
> FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
>
> I use the kqemu kernel module.  All software (kernel, /usr/ports) are
> up-to-date as of yesterday.

I suggest that you use a newer version, even though kqemu support has 
been removed there.

Paolo

[Qemu-devel] Re: Which qemu ports actually work?

[Torbjorn Granlund]

Paolo Bonzini <pbonzini@redhat.com> writes:

  On 10/26/2010 09:12 PM, Torbjorn Granlund wrote:
  > FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
  >
  > I use the kqemu kernel module.  All software (kernel, /usr/ports) are
  > up-to-date as of yesterday.
  
  I suggest that you use a newer version, even though kqemu support has
  been removed there.
  
Newer version of what?  FreeBSD 8.1-RELENG updated yesterday, and a
ports tree from yesterday, are new in my world!

Or do you mean to use FreeBSD CURRENT?  That's not an alternative for
me, I am running on production machines.  (And if kqemu is gone, that's
not an improvement...)

-- 
Torbjörn

[Qemu-devel] Re: Which qemu ports actually work?

[Stefan Weil]

Am 26.10.2010 22:07, schrieb Torbjorn Granlund:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> On 10/26/2010 09:12 PM, Torbjorn Granlund wrote:
> > FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
> >
> > I use the kqemu kernel module. All software (kernel, /usr/ports) are
> > up-to-date as of yesterday.
>
> I suggest that you use a newer version, even though kqemu support has
> been removed there.
>
> Newer version of what? FreeBSD 8.1-RELENG updated yesterday, and a
> ports tree from yesterday, are new in my world!
>
> Or do you mean to use FreeBSD CURRENT? That's not an alternative for
> me, I am running on production machines. (And if kqemu is gone, that's
> not an improvement...)
>

No, you need newer version of qemu, for example version 0.13.0
(see http://wiki.qemu.org/Main_Page) or latest qemu version
from the qemu git repository.

kqemu was replaced by kvm support (at least for some platforms).

As far as I know, there should be kvm support for FreeBSD, too,
but I must admit that I rarely use kvm: for most guests
which you listed neither kqemu nor kvm will be useable.
Both only improve host architecture = guest architecture
scenarios.

[Qemu-devel] Re: Which qemu ports actually work?

[Torbjorn Granlund]

Stefan Weil <weil@mail.berlios.de> writes:

  No, you need newer version of qemu, for example version 0.13.0
  
That's the version I am using:

king# qemu -version
QEMU emulator version 0.13.0, Copyright (c) 2003-2008 Fabrice Bellard

  kqemu was replaced by kvm support (at least for some platforms).
  
Are you talking about the FreeBSD kernel now and not the kernel Linux?

(I have a poor understanding of what the various components do, such as
kqemu and kvm.  Is there a good, accurate and quite detailed text about
this, that I could read?)

  As far as I know, there should be kvm support for FreeBSD, too,
  but I must admit that I rarely use kvm: for most guests
  which you listed neither kqemu nor kvm will be useable.
  Both only improve host architecture = guest architecture
  scenarios.

I realise that.

-- 
Torbjörn

[Qemu-devel] Re: Which qemu ports actually work?

[Paolo Bonzini]

On 10/26/2010 10:07 PM, Torbjorn Granlund wrote:
>    On 10/26/2010 09:12 PM, Torbjorn Granlund wrote:
>    >  FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
>    >
>    >  I use the kqemu kernel module.  All software (kernel, /usr/ports) are
>    >  up-to-date as of yesterday.
>
>    I suggest that you use a newer version, even though kqemu support has
>    been removed there.
>
> Newer version of what?  FreeBSD 8.1-RELENG updated yesterday, and a
> ports tree from yesterday, are new in my world!
>
> Or do you mean to use FreeBSD CURRENT?  That's not an alternative for
> me, I am running on production machines.  (And if kqemu is gone, that's
> not an improvement...)

I meant of QEMU.  I thought it was an old version because of the kqemu 
reference.  However, if you're using 0.13.0 as you wrote to Alex, then 
you're actually not using kqemu.

Paolo

Re: [Qemu-devel] Which qemu targets actually work? (was: Which qemu ports actually work?)

[Andreas Färber]

Am 26.10.2010 um 18:38 schrieb Torbjorn Granlund:

>         fbsd-8_1       nbsd-5_0_2    debian-5      gentoo        hurd
>
> sparc      n/a          OK            n/a           n/a           n/a
>
> sparc64    fw crash     fw crash      kern crash    black fb      n/a
>
> ppc        early hang   fw crash      OK            kern hang     n/a
>
> ppc64      early panic  fw crash      kern hang     kern hang     n/a
>
> i386       OK           OK            OK                           
> installs,
>                                                                  non- 
> booting
> x86_64     OK           OK            OK

> Is this what I can expect from qemu today?  Are the goals of the qemu
> project to make the various ports operational for running these OS's?

You seem to mean QEMU emulation targets, not QEMU ports.

QEMU provides a machine emulation. Only some of its users are involved  
in ports of particular operating systems. So no, it is not the primary  
goal of QEMU to make, e.g., FreeBSD 8.1 work, but any research why it  
doesn't and, best, patches to fix/improve it are welcome.

You didn't mention which version of QEMU you tried. The Git version is  
usually ahead of any stable release.
For ppc and sparc in particular, QEMU uses an OpenBIOS firmware, of  
which even newer versions are available from its SVN repository. (See  
the -bios option)

Andreas

Re: [Qemu-devel] Which qemu ports actually work?

[Blue Swirl]

On Tue, Oct 26, 2010 at 4:38 PM, Torbjorn Granlund <tg@gmplib.org> wrote:
> I am not sure this inquiry is appropriate for this mailing list.  But at
> the qemu web site, this is the only mailing list mentioned.
>
> I would like to run as many OS's as possible under as many processors as
> possible, using qemu.  Results thus far has not been very encouraging,
> though.
>
> Here is my test matrix:
>
>         fbsd-8_1       nbsd-5_0_2    debian-5      gentoo        hurd
>
> sparc      n/a          OK            n/a           n/a           n/a

OpenBSD also works.

About old versions, Debian 4 was the last version for Sparc32, it will
work. Gentoo 1.4 and 2004.1 had Sparc32 versions and those also boot.
Some Solaris versions should boot but crash (this is related to
OpenBIOS).

> sparc64    fw crash     fw crash      kern crash    black fb      n/a

That's about it, though I don't think fw crashes.

> ppc        early hang   fw crash      OK            kern hang     n/a
>
> ppc64      early panic  fw crash      kern hang     kern hang     n/a

Gentoo 2008.0 CD boots to installer, I don't know if it crashes later.

> i386       OK           OK            OK                          installs,
>                                                                  non-booting
> x86_64     OK           OK            OK
>
> These are results from multiple attempts and google searches for what
> other people have done.  Unfortunately, there aren't many matches,
> except that the various error messages I get have been experienced by
> several other people.
>
> Is this what I can expect from qemu today?  Are the goals of the qemu
> project to make the various ports operational for running these OS's?
> If yes, what is the time frame?
>
> It would be nice with a status page (there is a blank such page already,
> I mean a non-blank page...) informing about the status of the various
> ports.  A naive user--such as myself--tends to assume that a released
> port actually works.  It takes many hours of poorly used effort before
> one can conclude that e.g., sparc64 does not work at all.

The old web site had a status page, but we lost that when switching to Wiki.