On Wed, Apr 18, 2018 at 01:52:19PM +0200, Laszlo Ersek wrote:
> On 04/18/18 11:43, Paolo Bonzini wrote:
> > On 18/04/2018 00:40, Laszlo Ersek wrote:
> >> +#
> >> +# Lists firmware types commonly used with QEMU virtual machines.
> >> +#
> >> +# @bios: The firmware was built from the SeaBIOS project.
> >> +#
> >> +# @slof: The firmware was built from the Slimline Open Firmware project.
> >> +#
> >> +# @uboot: The firmware was built from the U-Boot project.
> >> +#
> >> +# @uefi: The firmware was built from the edk2 (EFI Development Kit II) project.
> >> +#
> >> +# Since: 2.13
> >> +##
> >> +{ 'enum' : 'FirmwareType',
> >> + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
> >
> > A very basic question (so not likely a suggestion for change). Why
> > wouldn't these be features too? For example a UEFI with CSM could
> > expose both uefi and bios, a u-boot with UEFI support could expose both
> > uboot and uefi, etc.
>
> Good point. I considered "type" to be a given, from the initial
> brainstorming, but if Dan is OK with your suggestion, I can turn these
> into features as well.
>
> > Perhaps there are two dimensions, the FirmwareType tells you how to
> > configure it and the FirmwareFeature tells you the APIs it exposes to
> > the guest?
>
> I don't know enough firmware types to answer this :) I believe I agree
> about the FirmwareFeature statement (if we also include "platform
> requirements" there), but I have no clue about any generalizations for
> firmware configuration.
IIUC Paolo is basically suggesting
{
"description": "OVMF firmware"
"type": "uefi",
"features": [
"uefi",
"bios"
],
}
where 'bios' is only listed if CSM is enabled in the OVMF build. I tend
to think that is redundant and we could just do
{
"description": "OVMF firmware"
"features": [
"uefi",
"bios"
],
}
And declare the order of "features" list is significant. ie
"features": [
"uefi",
"bios"
],
means a UEFI firmware which has back compat for BIOS (ie OVMF with CSM)
while
"features": [
"bios"
"uefi",
],
means a traditional BIOS firmware with compat for UEFI (thinking uboot
being able to include uefi support in this case)
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
