On Mon, 10 Feb 2020 at 07:56, David Gibson <da...@gibson.dropbear.id.au> wrote: > On Fri, Feb 07, 2020 at 12:45:20AM +0100, Paolo Bonzini wrote: > > Every platform that QEMU supports is just using a firmware to do > > firmware things; it can be U-Boot, EDK-2, SLOF, SeaBIOS, qboot, with > > varying level of complexity. Some are doing -kernel in QEMU rather than > > firmware, but that's where things end. > > Well, yeah, but AIUI those platforms actually have a defined hardware > environment on which the firmware is running. For PAPR we don't, we > *only* have a specification for the "hardware"+"firmware" environment > as seen by the OS together.
(The below is not intended to be a prescription for what PPC should do, just some background info about what we're doing with Arm currently.) For Arm our 'virt' board is drifting a bit towards doing some 'firmware' ABIs in QEMU -- currently this mostly means PSCI (for CPU power on/off, system reset, etc), but there have been proposals for other firmware ABIs that are hard to implement in guest firmware. I tend to agree with Paolo in principle that where possible keeping QEMU to "we implement some hardware emulation" and having firmware running in the guest is a nicer separation of concerns, though, so for Arm I'd like to avoid ending up with a lot of firmware-equivalent code in QEMU. FWIW for the Arm 'virt' board there is no defined hardware spec in the "handed down from elsewhere" sense -- so we defined our own (and some mechanisms for passing the device tree description of it into the guest firmware). thanks -- PMM
