[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Alexander Graf]

On 19.12.2010, at 20:12, Andreas Färber wrote:

> Am 19.12.2010 um 16:34 schrieb Alexander Graf:
> 
>> On 19.12.2010, at 16:04, Andreas Färber wrote:
>> 
>>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
>>> 
>>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M prep,
>>>>> with kind support from Hervé Poussineau here's an initial stab at
>>>>> fixing the long-broken PReP emulation and preparing migration from
>>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware.
>>>>> 
>>>>> In particular a number of hw_error()s are resolved, so that the BIOS
>>>>> can be entered at all. It is not yet working in terms of serial and
>>>>> VGA support etc.
>>>>> 
>>>>> This series is also available from:
>>>>> 
>>>>> git://repo.or.cz/qemu/afaerber.git prep-queue
>>>>> 
>>>>> Some more work-in-progress for the curious is on my prep branch [2].
>>>>> The corresponding work-in-progress OpenBIOS changes are at [3].
>>>>> 
>>>>> Unfortunately the prep machine is lacking documentation what exactly it
>>>>> tries to emulate. The plan thus is to merge emulation of a second, real
>>>>> IBM 40p machine based on Hervé's work at [1], for use with original
>>>>> binary firmware.
>>>>> 
>>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld,
>>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the
>>>>> POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port
>>>>> of OpenBIOS to be completed though. This relates to PReP in that the
>>>>> machine IDs will need to be coordinated.
>>>> 
>>>> Does this series actually make anything work, or is it just a first step 
>>>> set to get your development rolling? IOW, would users benefit from having 
>>>> the patches upstream yet?
>>> 
>>> As indicated above, it lets you enter a BIOS, which is a user-visible 
>>> improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware 
>>> with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for 
>>> testing the preceding patches and still needs investigation.
>>> 
>>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, 
>>> patches to OpenBIOS. Unless of course we want to use another firmware like 
>>> OFW from the start. The main interest in PReP nowadays will be proprietary 
>>> firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for 
>>> QEMU at some point but I couldn't locate them in the Aboriginal Linux tree.
>> 
>> I'm not sure on the copyright problems we might run into when delivering 
>> binary firmware.
> 
> No one suggested shipping proprietary firmware.
> 
> I was advocating enabling users to use the available firmware rather than 
> holding fixes back just because there is no fully-working FOSS alternative 
> firmware yet.

Hrm, I only partially agree. If you ship a target in qemu that people can't 
test out of the box, it won't receive testing from contributers. I doubt that 
RH people will go in and download proprietary firmware just to check that prep 
didn't break. I do hope however, that they test targets that "just work".

I have this very issue with s390. The only host to run (and compile) this on is 
an s390. And few people have those. So it breaks from time to time.

Since prep would at least get built for everyone, there's less of an issue, yes.

> 
>> So we certainly do need some open source firmware solution for prep to at 
>> least have Linux running. For other guests, I don't see a reason why users 
>> shouldn't try to fetch a real firmware blob separately :).
> 
> We're not shipping any firmware for ppcemb either, so that argument seems 
> moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to 
> supply additional blobs for U-Boot etc.

IIUC you don't need u-boot for the embedded targets. You just pass in a kernel 
and the rest is magic.

> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want 
> to run using open source firmware?
> I certainly do not intend to write firmware for the upcoming 40p machine. If 
> Linux runs on real 40p hardware then it should run with real firmware under 
> emulation, too. QEMU is an emulation project, not a Linux testing framework.

I completely agree. Linux is usually easy because it's fully open source and 
supports a lot of targets. If you feel like running NetBSD or Haiku instead, 
feel free to do so.

I'd even be willing to say that running any OS with a proprietary firmware blob 
is enough to pull stuff in. And really, I mean _any_ OS. I just really want to 
see some value for users, so in case the whole system just doesn't work at all, 
we can rather apply a big bunch of removal commits instead of fixes that won't 
end up in anything working either.

Having said that, I have faith in your skills to get this working. So I assume 
you'll have something that meets the "something runs" criteria in at most a 
couple of weeks. Shouldn't be too bad, no? :)


Alex