Re: [Qemu-devel] [ADD] PPC processor emulation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> >   But on the MacOS front if we can glom code
> > from MacOnLinux - or beef up user space mode and emulate the MOL kernel
> > module - then we could get everything from 8.6 to 10.3 working.  The older
> > MacOS's are actually tougher because you have to have a Mac ROM.
> > 
> Well, we'll need somthing like an OpenFirmware for recent MacOS too. I
> don't think there is a free firmware available for PPC which would be as
> complete as freebios... OpenBios seems far from this, as far as I
> know...

You don't need much. You need a device-tree and a few client interface
calls. MOL does that already and it makes all MacOS "newworld" and
OS X happy.

> > 	MOL can't run a "stock" Linux kernel, yet... the problem with
> > LinuxPPC is there *is* no such thing as a stock kernel, unless you
> > actually emulate Mac HW.

Well... You can since MOL do have the option of emulating some Mac HW ;)

The "native" bridge drivers were added to MOL later on, first versions
did indeed only HW emulation
 
> But a real Mac would be difficult to fully emulate, as I think it uses
> some obscure components. We can imagine the way it runs, looking at
> Darwin's code, sure...

And the linux/ppc one :) Actually, you really don't need to emulate
much HW to get any of the MacOSes up. Especially true with Darwin
where you can feed the Mach kernel with proper platform drivers at
boot time. For MacOS 9, you need some bits (PCI config space,
interrupt controller, via-cuda, ...) but for most things like block
storage, networking, etc..., MOL just feeds MacOS with special
drivers from the device-tree that do the bridging. It's all in
MOL source which is GPL and so can be reused here.

> But MacOs is supposed to run on PREP, which is well described and share
> a lot of components with PC hardwares. That's why I think it would be a
> good start to emulate this platform...

I don't think it's that nice ;) I'd rather go the mac way :)

> > > In my opinion, the hardest points are: PPC emulation improvement,
> > > cleaning the current vl code to separate x86 dedicated parts from
> > > generic ones and PCI. But I don't think we have to worry about PCI: x86
> > > emulation will need it too :=)
> > 
> > 	Yup... it's kind of surreal to play with Linux under qemu - "ppro"
> > cpu, but with 486-era peripherals... and more importantly using bus
> > mastered IO will be much more efficient.  I wonder if the bochs code could
> > be used as a reference for at least some of it, although I think they
> > mostly emulate ISA stuff too (and yet need the speed boost much more ;) )
> > 
> Yes, and we miss AGP & hyper-transport too :=).
> Seriously, I also think bochs is mainly based on ISA. I took a look to
> FreeBios: it doesn't allocate PCI ressources at boot time,
> so all PCI stuff are quite hardcoded in the drivers. There are a few:
> PCI host bridge, PCI to ISA bridge, VGA controler and USB.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>