[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [PATCH qemu v13] spapr: Implement Open Firmware client interface
Date: Tue, 23 Feb 2021 10:12:01 +0100 (CET)

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

Hmm, I hadn't thought of that sort of application.  I guess that's a

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

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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]