qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"
Date: Wed, 18 Apr 2018 13:03:20 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

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 :|



reply via email to

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