Re: [PATCH qemu v13] spapr: Implement Open Firmware client interface

From: BALATON Zoltan <balaton@eik.bme.hu>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH qemu v13] spapr: Implement Open Firmware client interface
Date: Tue, 23 Feb 2021 10:12:01 +0100 (CET)	[thread overview]
Message-ID: <d8d7fed-5c74-9755-fa34-10d97e9319cd@eik.bme.hu> (raw)
In-Reply-To: <YDSSgrTDipRIq2Lx@yekko.fritz.box>

On Tue, 23 Feb 2021, David Gibson wrote:
> On Tue, Feb 23, 2021 at 04:01:00PM +1100, Alexey Kardashevskiy wrote:
>> On 23/02/2021 14:07, David Gibson wrote:
>>> On Tue, Feb 09, 2021 at 10:02:52PM +1100, Alexey Kardashevskiy wrote:
>>>>   #endif /* HW_SPAPR_H */
>>>
>>> VOF is pretty much inherently papr specific, so I'm not really seeing
>>> a clear rationale for the distinction between vof_*() things and
>>> spapr_vof_*() things.
>>
>> spapr_vof_ uses SpaprMachineState, vof_ does not and can be used ... I do
>> not know... for macs? freescale?
>>
>> I thought it might be useful for whatever Balaton Zoltran wanted to use it
>> for.
>
> Hmm, I hadn't thought of that sort of application.  I guess that's a
> point.
>
> I feel like the call for vof is less for those platforms, because they
> admit a full in-guest firmware implementation, whereas the paravirt
> nature of papr means that some components have to go into the
> hypervisor.

The immediate plan is to try to use vof for pegasos2 as replacement 
firmware to be able to at least boot guests without needing a 
non-distributable firmware blob (as mentioned and further explained on 
https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2). This seems to be 
a better option than reimplementing its firmware which would then be yet 
another OpenFirmware implementation in QEMU. I was waiting for vof to get 
in before trying to actually implement that to avoid to need too much 
rebasing but in theory it could work. It's true we don't have a hypervisor 
on those platforms but could have one at least while the firmware is 
running to avoid having to do everything in guest firmware. Most guests 
just query the device tree via client interface and vof should be enough 
for that. I'm not sure about RTAS but that's a small problem if this 
allows to boot guests without having to write a whole guest open firmware 
implementation.

>>> Vof is pretty unavoidably tied to spapr, so I don't think you really
>>> need an interface to abstract this.
>>
>> Balaton Zoltran asked for that, more or less :)

This was my original comment:
https://lists.nongnu.org/archive/html/qemu-ppc/2020-12/msg00063.html

One reason is to keep vof reusable but also to make it clear what are the 
changes to spapr that was previously hard to distinguish from what's part 
of vof itself.

Regards,
BALATON Zoltan