11:46 a.m.
For Fedora 6 & 7, the virtualization management stack based on libvirt was
never built for PPC. This is because it depended on Xen which was x86(_64)
only. Since libvirt now has support for managing QEMU / KVM too, and QEMU
RPMs are available on PPC in Fedora, we have removed the ExcludeArch from
all the virt management RPMs. Xen support in libvirt is still explicitly
excluded on PPC - we only build QEMU support. The build was just completed
so RPMs should be available in rawhide in the near future.
If the kernel-xen in Fedora ever gets PPC support we can also enable libvirt
to support Xen on PPC, but that's blocked on PPC kernel merge & not aware of
anyone actively working on that.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
12:41 p.m.
On Fri, 24 Aug 2007 17:46:16 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
For Fedora 6 & 7, the virtualization management stack based on
libvirt was never built for PPC. This is because it depended on Xen
which was x86(_64) only. Since libvirt now has support for managing
QEMU / KVM too, and QEMU RPMs are available on PPC in Fedora, we have
removed the ExcludeArch from all the virt management RPMs. Xen
support in libvirt is still explicitly excluded on PPC - we only
build QEMU support. The build was just completed so RPMs should be
available in rawhide in the near future.
If the kernel-xen in Fedora ever gets PPC support we can also enable
libvirt to support Xen on PPC, but that's blocked on PPC kernel merge
& not aware of anyone actively working on that.
So I'm not sure how you'd prevent this, but qemu cannot emulate
usefully a fully working ppc(64) guest. There are lots of problems
there, and a non-existant upstream for it. So you might be able to use
libvirt + qemu to emulate x86 on ppc, but not ppc itself.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
12:59 p.m.
On Fri, Aug 24, 2007 at 01:41:54PM -0400, Jesse Keating wrote:
On Fri, 24 Aug 2007 17:46:16 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> For Fedora 6 & 7, the virtualization management stack based on
> libvirt was never built for PPC. This is because it depended on Xen
> which was x86(_64) only. Since libvirt now has support for managing
> QEMU / KVM too, and QEMU RPMs are available on PPC in Fedora, we have
> removed the ExcludeArch from all the virt management RPMs. Xen
> support in libvirt is still explicitly excluded on PPC - we only
> build QEMU support. The build was just completed so RPMs should be
> available in rawhide in the near future.
>
> If the kernel-xen in Fedora ever gets PPC support we can also enable
> libvirt to support Xen on PPC, but that's blocked on PPC kernel merge
> & not aware of anyone actively working on that.
So I'm not sure how you'd prevent this, but qemu cannot emulate
usefully a fully working ppc(64) guest. There are lots of problems
there, and a non-existant upstream for it. So you might be able to use
libvirt + qemu to emulate x86 on ppc, but not ppc itself.
Ah that's useful info - i saw a qemu-system-ppc binary in the QEMU RPM
and thus assumed it was working. If it doesn't work we can easily change
the whitelist in libvirt - we basically just list all qemu-system-XXX
binaries which we think work reasonably.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
3:43 p.m.
On Fri, 2007-08-24 at 18:59 +0100, Daniel P. Berrange wrote:
> So I'm not sure how you'd prevent this, but qemu cannot
emulate
> usefully a fully working ppc(64) guest. There are lots of problems
> there, and a non-existant upstream for it. So you might be able to use
> libvirt + qemu to emulate x86 on ppc, but not ppc itself.
Ah that's useful info - i saw a qemu-system-ppc binary in the QEMU RPM
and thus assumed it was working. If it doesn't work we can easily change
the whitelist in libvirt - we basically just list all qemu-system-XXX
binaries which we think work reasonably.
I don't think there's any particular problem with qemu-system-ppc per
se; it's more the _firmware_ we use in it, which is a quick hack which
was just about sufficient to get older kernels (and AIX etc.) working.
These days, it isn't really sufficient. New kernels expect a sane and
complete device-tree, etc.
At some point in my Copious Spare Time™ I mean to try to fix it, or
maybe even port the version of OpenFirmware that we're using on OLPC.
Spare time hasn't exactly been copious recently though :)
--
dwmw2
6:24 p.m.
On Sat, 25 Aug 2007 21:43:24 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
On Fri, 2007-08-24 at 18:59 +0100, Daniel P. Berrange wrote:
> > So I'm not sure how you'd prevent this, but qemu cannot emulate
> > usefully a fully working ppc(64) guest. There are lots of problems
> > there, and a non-existant upstream for it. So you might be able to use
> > libvirt + qemu to emulate x86 on ppc, but not ppc itself.
>
> Ah that's useful info - i saw a qemu-system-ppc binary in the QEMU RPM
> and thus assumed it was working. If it doesn't work we can easily change
> the whitelist in libvirt - we basically just list all qemu-system-XXX
> binaries which we think work reasonably.
I don't think there's any particular problem with qemu-system-ppc per
se; it's more the _firmware_ we use in it, which is a quick hack which
was just about sufficient to get older kernels (and AIX etc.) working.
These days, it isn't really sufficient. New kernels expect a sane and
complete device-tree, etc.
At some point in my Copious Spare Time™ I mean to try to fix it, or
maybe even port the version of OpenFirmware that we're using on OLPC.
Spare time hasn't exactly been copious recently though :)
In the meantime, David Gibson and Rob Landley have been working on
porting PReP to arch/powerpc. Rob is using qemu as his "platform", so
there may be some kernels that run on it as-is soon.
josh
9:30 p.m.
On Sat, 25 Aug 2007 18:24:13 -0500
Josh Boyer <jwboyer(a)jdub.homelinux.org> wrote:
> I don't think there's any particular problem with
qemu-system-ppc
> per se; it's more the _firmware_ we use in it, which is a quick
> hack which was just about sufficient to get older kernels (and AIX
> etc.) working. These days, it isn't really sufficient. New kernels
> expect a sane and complete device-tree, etc.
>
> At some point in my Copious Spare Time™ I mean to try to fix it, or
> maybe even port the version of OpenFirmware that we're using on
> OLPC. Spare time hasn't exactly been copious recently though :)
In the meantime, David Gibson and Rob Landley have been working on
porting PReP to arch/powerpc. Rob is using qemu as his "platform", so
there may be some kernels that run on it as-is soon.
I though that even with a working firmware the kernel was pretty much
hosed to run in qemu. I could be wrong though, happy to be. If I
could do my ppc tree testing emulated like while working remotely I'd
be a very happy hacker.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
3:40 a.m.
On Sat, 2007-08-25 at 22:30 -0400, Jesse Keating wrote:
I though that even with a working firmware the kernel was pretty
much
hosed to run in qemu. I could be wrong though, happy to be. If I
could do my ppc tree testing emulated like while working remotely I'd
be a very happy hacker.
I poked at it for a while, a few weeks ago. Booting is fairly screwy
because qemu seems to handle the '-kernel' image just as if it was a
hard drive. That might work for an i386 kernel which I think is still
mostly set up to be started from a floppy disk, but doesn't really work
too well when your kernel is an ELF file :)
You can boot it from a CD image, but its firmware doesn't actually run
FORTH scripts -- it just checks the CRC on them to see if they're
something it "knows", and takes appropriate action if so. It didn't know
the script we use on the Fedora boot media to check for 32-bit vs.
64-bit hardware, so it did nothing.
I hacked it to deal with that, and was putting my test kernels onto a
filesystem in a real hard drive image -- and the kernels were _starting_
to boot. Then I had MMU initialisation issues because the memory wasn't
correctly described in the device-tree. After I worked around that, it
crashed in IRQ controller initialisation, almost certainly also due to
lack of correct information in the device-tree. All of this was before
you see any _output_, so I had to connect to qemu with gdb and dump the
contents of the printk log buffer to see what was going on.
So you're right that if we work around the fact that the firmware can't
actually load a kernel, the kernel does crash. But I actually think
that's due to firmware problems too.
--
dwmw2
6081
days inactive
6083
days old
6 comments
4 participants
participants (4)
-
Daniel P. Berrange -
David Woodhouse -
Jesse Keating -
Josh Boyer