qemu-devel
[Top][All Lists]
Advanced

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

Re: VW ELF loader


From: Peter Maydell
Subject: Re: VW ELF loader
Date: Mon, 10 Feb 2020 10:37:19 +0000

On Mon, 10 Feb 2020 at 07:56, David Gibson <address@hidden> 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



reply via email to

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