Re: [libvirt] [qemu RFC] qapi: add "firmware.json"

On 04/09/18 09:26, Thomas Huth wrote: > Hi Laszlo, > > On 07.04.2018 02:01, Laszlo Ersek wrote: >> Add a schema that describes the properties of virtual machine firmware. >> >> Each firmware executable installed on a host system should come with a >> JSON file that conforms to this schema, and informs the management >> applications about the firmware's properties. >> >> In addition, a configuration directory with symlinks to the JSON files >> should exist, with the symlinks carefully named to reflect a priority >> order. Management applications can then search this directory in priority >> order for the first firmware executable that satisfies their search >> criteria. The found JSON file provides the management layer with domain >> configuration bits that are required to run the firmware binary. > [...] >> +## >> +# @FirmwareDevice: >> +# >> +# Defines the device types that a firmware file can be mapped into. >> +# >> +# @memory: The firmware file is to be mapped into memory. >> +# >> +# @kernel: The firmware file is to be loaded like a Linux kernel. This is >> +# similar to @memory but may imply additional processing that is >> +# specific to the target architecture. >> +# >> +# @flash: The firmware file is to be mapped into a pflash chip. >> +# >> +# Since: 2.13 >> +## >> +{ 'enum' : 'FirmwareDevice', >> + 'data' : [ 'memory', 'kernel', 'flash' ] } > > This is not fully clear to me... what is this exactly good for? Is this > a way to say how the firmware should be loaded, i.e. via "-bios", > "-kernel" or "-pflash" parameter? If so, the term "memory" is quite > misleading since files that are loaded via -bios can also end up in an > emulated ROM chip. I threw in "-kernel" because, although it also (usually?) means "memory", I expected people would want it separate. Regarding memory vs. pflash, I thought that these two, combined with the access permissions, could cover all of RAM, ROM, and read-only and read-write pflash too. So, "-bios" (-> ROM) boils down to "memory", with write access denied -- please see the SeaBIOS example near the end.

>> + 'nvram-map' : 'FirmwareMapping', >> + 'templates' : [ 'FirmwareFile' ] } } >> + >> +## >> +# @SystemFirmwareType: >> +# >> +# Lists system firmware types commonly used with QEMU virtual machines. >> +# >> +# @bios: The system firmware was built from the SeaBIOS project. >> +# >> +# @slof: The system firmware was built from the Slimline Open Firmware project. >> +# >> +# @uboot: The system firmware was built from the U-Boot project. >> +# >> +# @uefi: The system firmware was built from the edk2 (EFI Development Kit II) >> +# project. >> +# >> +# Since: 2.13 >> +## >> +{ 'enum' : 'SystemFirmwareType', >> + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] } > > The naming here is quite a bad mixture between firmware interface > ('bios', 'uefi') and firmware implementations ('slof', 'uboot'). There > could be other implementations of BIOS or UEFI than SeaBIOS and EDK2 ... > so I'd suggest to rather name them 'seabios' and 'edk2' here instead. Sure, I'm totally ready to follow community advice here (too). In fact this is the one element I dislike the most about the schema -- it's the fuzziest part, yet it is the most important element for libvirt. Because users and higher level apps just want to say "give me UEFI". If I have to ask "OK, but UEFI built from edk2 or something else?", then it's a lost cause already. It's hard to find the right level of abstraction in the naming when the higher level tools (and/or ultimately the users) don't know enough to ask for specifics -- I'm not saying that's bad; it's quite natural, but makes things very difficult. So this enum aims to match the user story "gimme UEFI and be done with it". I figure users will just utter the most common buzzword form of the concept they have in mind. "edk2" doesn't tell them as much as "uefi".