| # -*- Mode: Python -*- |
| # vim: filetype=python |
| # |
| # Copyright (C) 2018 Red Hat, Inc. |
| # |
| # Authors: |
| # Daniel P. Berrange <berrange@redhat.com> |
| # Laszlo Ersek <lersek@redhat.com> |
| # |
| # This work is licensed under the terms of the GNU GPL, version 2 or |
| # later. See the COPYING file in the top-level directory. |
| |
| ## |
| # ******** |
| # Firmware |
| # ******** |
| ## |
| |
| { 'pragma': { |
| 'member-name-exceptions': [ |
| 'FirmwareArchitecture' # x86_64 |
| ] } } |
| |
| ## |
| # @FirmwareOSInterface: |
| # |
| # Lists the firmware-OS interface types provided by various firmware |
| # that is commonly used with QEMU virtual machines. |
| # |
| # @bios: Traditional x86 BIOS interface. For example, firmware built |
| # from the SeaBIOS project usually provides this interface. |
| # |
| # @openfirmware: The interface is defined by the (historical) IEEE |
| # 1275-1994 standard. Examples for firmware projects that provide |
| # this interface are: OpenBIOS and SLOF. |
| # |
| # @uboot: Firmware interface defined by the U-Boot project. |
| # |
| # @uefi: Firmware interface defined by the UEFI specification. For |
| # example, firmware built from the edk2 (EFI Development Kit II) |
| # project usually provides this interface. |
| # |
| # Since: 3.0 |
| ## |
| { 'enum' : 'FirmwareOSInterface', |
| 'data' : [ 'bios', 'openfirmware', 'uboot', 'uefi' ] } |
| |
| ## |
| # @FirmwareDevice: |
| # |
| # Defines the device types that firmware can be mapped into. |
| # |
| # @flash: The firmware executable and its accompanying NVRAM file are |
| # to be mapped into a pflash chip each. |
| # |
| # @kernel: The firmware 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 and machine type. |
| # |
| # @memory: The firmware is to be mapped into memory. |
| # |
| # @igvm: The firmware is defined by a file conforming to the IGVM |
| # specification and mapped into memory according to directives |
| # defined in the file. This is similar to @memory but may include |
| # additional processing defined by the IGVM file including initial |
| # CPU state or population of metadata into the guest address |
| # space. Since: 10.1 |
| # |
| # Since: 3.0 |
| ## |
| { 'enum' : 'FirmwareDevice', |
| 'data' : [ 'flash', 'kernel', 'memory', 'igvm' ] } |
| |
| ## |
| # @FirmwareArchitecture: |
| # |
| # Enumeration of architectures for which Qemu uses additional firmware |
| # files. |
| # |
| # @aarch64: 64-bit Arm. |
| # |
| # @arm: 32-bit Arm. |
| # |
| # @i386: 32-bit x86. |
| # |
| # @loongarch64: 64-bit LoongArch. (since: 7.1) |
| # |
| # @riscv64: 64-bit RISC-V. |
| # |
| # @x86_64: 64-bit x86. |
| # |
| # Since: 3.0 |
| ## |
| { 'enum' : 'FirmwareArchitecture', |
| 'data' : [ 'aarch64', 'arm', 'i386', 'loongarch64', 'riscv64', 'x86_64' ] } |
| |
| ## |
| # @FirmwareTarget: |
| # |
| # Defines the machine types that firmware may execute on. |
| # |
| # @architecture: Determines the emulation target (the QEMU system |
| # emulator) that can execute the firmware. |
| # |
| # @machines: Lists the machine types (known by the emulator that is |
| # specified through @architecture) that can execute the firmware. |
| # Elements of @machines are supposed to be concrete machine types, |
| # not aliases. Glob patterns are understood, which is especially |
| # useful for versioned machine types. (For example, the glob |
| # pattern "pc-i440fx-*" matches "pc-i440fx-2.12".) On the QEMU |
| # command line, "-machine type=..." specifies the requested |
| # machine type (but that option does not accept glob patterns). |
| # |
| # Since: 3.0 |
| ## |
| { 'struct' : 'FirmwareTarget', |
| 'data' : { 'architecture' : 'FirmwareArchitecture', |
| 'machines' : [ 'str' ] } } |
| |
| ## |
| # @FirmwareFeature: |
| # |
| # Defines the features that firmware may support, and the platform |
| # requirements that firmware may present. |
| # |
| # @acpi-s3: The firmware supports S3 sleep (suspend to RAM), as |
| # defined in the ACPI specification. On the "pc-i440fx-*" machine |
| # types of the @i386 and @x86_64 emulation targets, S3 can be |
| # enabled with "-global PIIX4_PM.disable_s3=0" and disabled with |
| # "-global PIIX4_PM.disable_s3=1". On the "pc-q35-*" machine |
| # types of the @i386 and @x86_64 emulation targets, S3 can be |
| # enabled with "-global ICH9-LPC.disable_s3=0" and disabled with |
| # "-global ICH9-LPC.disable_s3=1". |
| # |
| # @acpi-s4: The firmware supports S4 hibernation (suspend to disk), as |
| # defined in the ACPI specification. On the "pc-i440fx-*" machine |
| # types of the @i386 and @x86_64 emulation targets, S4 can be |
| # enabled with "-global PIIX4_PM.disable_s4=0" and disabled with |
| # "-global PIIX4_PM.disable_s4=1". On the "pc-q35-*" machine |
| # types of the @i386 and @x86_64 emulation targets, S4 can be |
| # enabled with "-global ICH9-LPC.disable_s4=0" and disabled with |
| # "-global ICH9-LPC.disable_s4=1". |
| # |
| # @amd-sev: The firmware supports running under AMD Secure Encrypted |
| # Virtualization, as specified in the AMD64 Architecture |
| # Programmer's Manual. QEMU command line options related to this |
| # feature are documented in |
| # "docs/system/i386/amd-memory-encryption.rst". |
| # |
| # @amd-sev-es: The firmware supports running under AMD Secure |
| # Encrypted Virtualization - Encrypted State, as specified in the |
| # AMD64 Architecture Programmer's Manual. QEMU command line |
| # options related to this feature are documented in |
| # "docs/system/i386/amd-memory-encryption.rst". |
| # |
| # @amd-sev-snp: The firmware supports running under AMD Secure |
| # Encrypted Virtualization - Secure Nested Paging, as specified in |
| # the AMD64 Architecture Programmer's Manual. QEMU command line |
| # options related to this feature are documented in |
| # "docs/system/i386/amd-memory-encryption.rst". |
| # |
| # @intel-tdx: The firmware supports running under Intel Trust Domain |
| # Extensions (TDX). |
| # |
| # @enrolled-keys: The variable store (NVRAM) template associated with |
| # the firmware binary has the UEFI Secure Boot operational mode |
| # turned on, with certificates enrolled. |
| # |
| # @requires-smm: The firmware requires the platform to emulate SMM |
| # (System Management Mode), as defined in the AMD64 Architecture |
| # Programmer's Manual, and in the Intel(R)64 and IA-32 |
| # Architectures Software Developer's Manual. On the "pc-q35-*" |
| # machine types of the @i386 and @x86_64 emulation targets, SMM |
| # emulation can be enabled with "-machine smm=on". (On the |
| # "pc-q35-*" machine types of the @i386 emulation target, |
| # @requires-smm presents further CPU requirements; one combination |
| # known to work is "-cpu coreduo,nx=off".) If the firmware is |
| # marked as both @secure-boot and @requires-smm, then write |
| # accesses to the pflash chip (NVRAM) that holds the UEFI variable |
| # store must be restricted to code that executes in SMM, using the |
| # additional option "-global |
| # driver=cfi.pflash01,property=secure,value=on". Furthermore, a |
| # large guest-physical address space (comprising guest RAM, memory |
| # hotplug range, and 64-bit PCI MMIO aperture), and/or a high VCPU |
| # count, may present high SMRAM requirements from the firmware. |
| # On the "pc-q35-*" machine types of the @i386 and @x86_64 |
| # emulation targets, the SMRAM size may be increased above the |
| # default 16MB with the "-global mch.extended-tseg-mbytes=uint16" |
| # option. As a rule of thumb, the default 16MB size suffices for |
| # 1TB of guest-phys address space and a few tens of VCPUs; for |
| # every further TB of guest-phys address space, add 8MB of SMRAM. |
| # 48MB should suffice for 4TB of guest-phys address space and 2-3 |
| # hundred VCPUs. |
| # |
| # @secure-boot: The firmware implements the software interfaces for |
| # UEFI Secure Boot, as defined in the UEFI specification. Note |
| # that without @requires-smm, guest code running with kernel |
| # privileges can undermine the security of Secure Boot. |
| # |
| # @verbose-dynamic: When firmware log capture is enabled, the firmware |
| # logs a large amount of debug messages, which may impact boot |
| # performance. With log capture disabled, there is no boot |
| # performance impact. On the "pc-i440fx-*" and "pc-q35-*" machine |
| # types of the @i386 and @x86_64 emulation targets, firmware log |
| # capture can be enabled with the QEMU command line options |
| # "-chardev file,id=fwdebug,path=LOGFILEPATH -device |
| # isa-debugcon,iobase=0x402,chardev=fwdebug". @verbose-dynamic is |
| # mutually exclusive with @verbose-static. |
| # |
| # @verbose-static: The firmware unconditionally produces a large |
| # amount of debug messages, which may impact boot performance. |
| # This feature may typically be carried by certain UEFI firmware |
| # for the "virt-*" machine types of the @arm and @aarch64 |
| # emulation targets, where the debug messages are written to the |
| # first (always present) PL011 UART. @verbose-static is mutually |
| # exclusive with @verbose-dynamic. |
| # |
| # @host-uefi-vars: The firmware expects the host to provide an uefi |
| # variable store. qemu supports that via "uefi-vars-sysbus" |
| # (aarch64, riscv64, loongarch64) or "uefi-vars-x64" (x86_64) |
| # devices. The firmware will not use flash for nvram. When |
| # loading the firmware into flash the 'stateless' setup should be |
| # used. It is recommened to load the firmware into memory though. |
| # |
| # Since: 3.0 |
| ## |
| { 'enum' : 'FirmwareFeature', |
| 'data' : [ 'acpi-s3', 'acpi-s4', |
| 'amd-sev', 'amd-sev-es', 'amd-sev-snp', |
| 'intel-tdx', |
| 'enrolled-keys', 'requires-smm', |
| 'secure-boot', 'host-uefi-vars', |
| 'verbose-dynamic', 'verbose-static' ] } |
| |
| ## |
| # @FirmwareFormat: |
| # |
| # Formats that are supported for firmware images. |
| # |
| # @raw: Raw disk image format. |
| # |
| # @qcow2: The QCOW2 image format. |
| # |
| # Since: 3.0 |
| ## |
| { 'enum': 'FirmwareFormat', |
| 'data': [ 'raw', 'qcow2' ] } |
| |
| ## |
| # @FirmwareFlashFile: |
| # |
| # Defines common properties that are necessary for loading a firmware |
| # file into a pflash chip. The corresponding QEMU command line option |
| # is "-drive file=@filename,format=@format". Note however that the |
| # option-argument shown here is incomplete; it is completed under |
| # @FirmwareMappingFlash. |
| # |
| # @filename: Specifies the filename on the host filesystem where the |
| # firmware file can be found. |
| # |
| # @format: Specifies the block format of the file pointed-to by |
| # @filename, such as @raw or @qcow2. |
| # |
| # Since: 3.0 |
| ## |
| { 'struct' : 'FirmwareFlashFile', |
| 'data' : { 'filename' : 'str', |
| 'format' : 'FirmwareFormat' } } |
| |
| |
| ## |
| # @FirmwareFlashMode: |
| # |
| # Describes how the firmware build handles code versus variable |
| # persistence. |
| # |
| # @split: the executable file contains code while the NVRAM template |
| # provides variable storage. The executable must be configured |
| # read-only and can be shared between multiple guests. The NVRAM |
| # template must be cloned for each new guest and configured |
| # read-write. |
| # |
| # @combined: the executable file contains both code and variable |
| # storage. The executable must be cloned for each new guest and |
| # configured read-write. No NVRAM template will be specified. |
| # |
| # @stateless: the executable file contains code and variable storage |
| # is not persisted. The executable must be configured read-only |
| # and can be shared between multiple guests. No NVRAM template |
| # will be specified. |
| # |
| # Since: 7.0.0 |
| ## |
| { 'enum': 'FirmwareFlashMode', |
| 'data': [ 'split', 'combined', 'stateless' ] } |
| |
| ## |
| # @FirmwareMappingFlash: |
| # |
| # Describes loading and mapping properties for the firmware executable |
| # and its accompanying NVRAM file, when @FirmwareDevice is @flash. |
| # |
| # @mode: Describes how the firmware build handles code versus variable |
| # storage. If not present, it must be treated as if it was |
| # configured with value @split. Since: 7.0.0 |
| # |
| # @executable: Identifies the firmware executable. The @mode |
| # indicates whether there will be an associated NVRAM template |
| # present. The preferred corresponding QEMU command line options |
| # are |
| # |
| # :: |
| # |
| # -drive if=none,id=pflash0,readonly=on,file=@executable.@filename,format=@executable.@format |
| # -machine pflash0=pflash0 |
| # |
| # or equivalent -blockdev instead of -drive. When @mode is |
| # @combined the executable must be cloned before use and |
| # configured with readonly=off. With QEMU versions older than |
| # 4.0, you have to use |
| # |
| # :: |
| # |
| # -drive if=pflash,unit=0,readonly=on,file=@executable.@filename,format=@executable.@format |
| # |
| # @nvram-template: Identifies the NVRAM template compatible with |
| # @executable, when @mode is set to @split, otherwise it should |
| # not be present. Management software instantiates an individual |
| # copy -- a specific NVRAM file -- from @nvram-template.@filename |
| # for each new virtual machine definition created. |
| # @nvram-template.@filename itself is never mapped into virtual |
| # machines, only individual copies of it are. An NVRAM file is |
| # typically used for persistently storing the non-volatile UEFI |
| # variables of a virtual machine definition. The preferred |
| # corresponding QEMU command line options are |
| # |
| # :: |
| # |
| # -drive if=none,id=pflash1,readonly=off,file=FILENAME_OF_PRIVATE_NVRAM_FILE,format=@nvram-template.@format |
| # -machine pflash1=pflash1 |
| # |
| # or equivalent -blockdev instead of -drive. With QEMU versions |
| # older than 4.0, you have to use |
| # |
| # :: |
| # |
| # -drive if=pflash,unit=1,readonly=off,file=FILENAME_OF_PRIVATE_NVRAM_FILE,format=@nvram-template.@format |
| # |
| # Since: 3.0 |
| ## |
| { 'struct' : 'FirmwareMappingFlash', |
| 'data' : { '*mode': 'FirmwareFlashMode', |
| 'executable' : 'FirmwareFlashFile', |
| '*nvram-template' : 'FirmwareFlashFile' } } |
| |
| ## |
| # @FirmwareMappingKernel: |
| # |
| # Describes loading and mapping properties for the firmware |
| # executable, when @FirmwareDevice is @kernel. |
| # |
| # @filename: Identifies the firmware executable. The firmware |
| # executable may be shared by multiple virtual machine |
| # definitions. The corresponding QEMU command line option is |
| # "-kernel @filename". |
| # |
| # Since: 3.0 |
| ## |
| { 'struct' : 'FirmwareMappingKernel', |
| 'data' : { 'filename' : 'str' } } |
| |
| ## |
| # @FirmwareMappingMemory: |
| # |
| # Describes loading and mapping properties for the firmware |
| # executable, when @FirmwareDevice is @memory. |
| # |
| # @filename: Identifies the firmware executable. The firmware |
| # executable may be shared by multiple virtual machine |
| # definitions. The corresponding QEMU command line option is |
| # "-bios @filename". |
| # |
| # Since: 3.0 |
| ## |
| { 'struct' : 'FirmwareMappingMemory', |
| 'data' : { 'filename' : 'str' } } |
| |
| ## |
| # @FirmwareMappingIgvm: |
| # |
| # Describes loading and mapping properties for the firmware |
| # executable, when @FirmwareDevice is @igvm. |
| # |
| # @filename: Identifies the IGVM file containing the firmware |
| # executable along with other information used to configure the |
| # initial state of the guest. The IGVM file may be shared by |
| # multiple virtual machine definitions. This corresponds to |
| # creating an object on the command line with "-object igvm-cfg, |
| # file=@filename". |
| # |
| # Since: 10.1 |
| ## |
| { 'struct' : 'FirmwareMappingIgvm', |
| 'data' : { 'filename' : 'str' } } |
| |
| ## |
| # @FirmwareMapping: |
| # |
| # Provides a discriminated structure for firmware to describe its |
| # loading / mapping properties. |
| # |
| # @device: Selects the device type that the firmware must be mapped |
| # into. |
| # |
| # Since: 3.0 |
| ## |
| { 'union' : 'FirmwareMapping', |
| 'base' : { 'device' : 'FirmwareDevice' }, |
| 'discriminator' : 'device', |
| 'data' : { 'flash' : 'FirmwareMappingFlash', |
| 'kernel' : 'FirmwareMappingKernel', |
| 'memory' : 'FirmwareMappingMemory', |
| 'igvm' : 'FirmwareMappingIgvm' } } |
| |
| ## |
| # @Firmware: |
| # |
| # Describes a firmware (or a firmware use case) to management |
| # software. |
| # |
| # It is possible for multiple @Firmware elements to match the search |
| # criteria of management software. Applications thus need rules to |
| # pick one of the many matches, and users need the ability to override |
| # distro defaults. |
| # |
| # It is recommended to create firmware JSON files (each containing a |
| # single @Firmware root element) with a double-digit prefix, for |
| # example "50-ovmf.json", "50-seabios-256k.json", etc, so they can be |
| # sorted in predictable order. The firmware JSON files should be |
| # searched for in three directories: |
| # |
| # - /usr/share/qemu/firmware -- populated by distro-provided firmware |
| # packages (XDG_DATA_DIRS covers |
| # /usr/share by default), |
| # |
| # - /etc/qemu/firmware -- exclusively for sysadmins' local additions, |
| # |
| # - $XDG_CONFIG_HOME/qemu/firmware -- exclusively for per-user local |
| # additions (XDG_CONFIG_HOME |
| # defaults to $HOME/.config). |
| # |
| # Top-down, the list of directories goes from general to specific. |
| # |
| # Management software should build a list of files from all three |
| # locations, then sort the list by filename (i.e., last pathname |
| # component). Management software should choose the first JSON file |
| # on the sorted list that matches the search criteria. If a more |
| # specific directory has a file with same name as a less specific |
| # directory, then the file in the more specific directory takes |
| # effect. If the more specific file is zero length, it hides the less |
| # specific one. |
| # |
| # For example, if a distro ships |
| # |
| # - /usr/share/qemu/firmware/50-ovmf.json |
| # |
| # - /usr/share/qemu/firmware/50-seabios-256k.json |
| # |
| # then the sysadmin can prevent the default OVMF being used at all |
| # with |
| # |
| # $ touch /etc/qemu/firmware/50-ovmf.json |
| # |
| # The sysadmin can replace/alter the distro default OVMF with |
| # |
| # $ vim /etc/qemu/firmware/50-ovmf.json |
| # |
| # or they can provide a parallel OVMF with higher priority |
| # |
| # $ vim /etc/qemu/firmware/10-ovmf.json |
| # |
| # or they can provide a parallel OVMF with lower priority |
| # |
| # $ vim /etc/qemu/firmware/99-ovmf.json |
| # |
| # @description: Provides a human-readable description of the firmware. |
| # Management software may or may not display @description. |
| # |
| # @interface-types: Lists the types of interfaces that the firmware |
| # can expose to the guest OS. This is a non-empty, ordered list; |
| # entries near the beginning of @interface-types are considered |
| # more native to the firmware, and/or to have a higher quality |
| # implementation in the firmware, than entries near the end of |
| # @interface-types. |
| # |
| # @mapping: Describes the loading / mapping properties of the |
| # firmware. |
| # |
| # @targets: Collects the target architectures (QEMU system emulators) |
| # and their machine types that may execute the firmware. |
| # |
| # @features: Lists the features that the firmware supports, and the |
| # platform requirements it presents. |
| # |
| # @tags: A list of auxiliary strings associated with the firmware for |
| # which @description is not appropriate, due to the latter's |
| # possible exposure to the end-user. @tags serves development and |
| # debugging purposes only, and management software shall |
| # explicitly ignore it. |
| # |
| # Since: 3.0 |
| # |
| # .. qmp-example:: |
| # |
| # { |
| # "description": "SeaBIOS", |
| # "interface-types": [ |
| # "bios" |
| # ], |
| # "mapping": { |
| # "device": "memory", |
| # "filename": "/usr/share/seabios/bios-256k.bin" |
| # }, |
| # "targets": [ |
| # { |
| # "architecture": "i386", |
| # "machines": [ |
| # "pc-i440fx-*", |
| # "pc-q35-*" |
| # ] |
| # }, |
| # { |
| # "architecture": "x86_64", |
| # "machines": [ |
| # "pc-i440fx-*", |
| # "pc-q35-*" |
| # ] |
| # } |
| # ], |
| # "features": [ |
| # "acpi-s3", |
| # "acpi-s4" |
| # ], |
| # "tags": [ |
| # "CONFIG_BOOTSPLASH=n", |
| # "CONFIG_ROM_SIZE=256", |
| # "CONFIG_USE_SMM=n" |
| # ] |
| # } |
| # |
| # { |
| # "description": "OVMF with SB+SMM, empty varstore", |
| # "interface-types": [ |
| # "uefi" |
| # ], |
| # "mapping": { |
| # "device": "flash", |
| # "executable": { |
| # "filename": "/usr/share/OVMF/OVMF_CODE.secboot.fd", |
| # "format": "raw" |
| # }, |
| # "nvram-template": { |
| # "filename": "/usr/share/OVMF/OVMF_VARS.fd", |
| # "format": "raw" |
| # } |
| # }, |
| # "targets": [ |
| # { |
| # "architecture": "x86_64", |
| # "machines": [ |
| # "pc-q35-*" |
| # ] |
| # } |
| # ], |
| # "features": [ |
| # "acpi-s3", |
| # "amd-sev", |
| # "requires-smm", |
| # "secure-boot", |
| # "verbose-dynamic" |
| # ], |
| # "tags": [ |
| # "-a IA32", |
| # "-a X64", |
| # "-p OvmfPkg/OvmfPkgIa32X64.dsc", |
| # "-t GCC48", |
| # "-b DEBUG", |
| # "-D SMM_REQUIRE", |
| # "-D SECURE_BOOT_ENABLE", |
| # "-D FD_SIZE_4MB" |
| # ] |
| # } |
| # |
| # { |
| # "description": "OVMF with SB+SMM, SB enabled, MS certs enrolled", |
| # "interface-types": [ |
| # "uefi" |
| # ], |
| # "mapping": { |
| # "device": "flash", |
| # "executable": { |
| # "filename": "/usr/share/OVMF/OVMF_CODE.secboot.fd", |
| # "format": "raw" |
| # }, |
| # "nvram-template": { |
| # "filename": "/usr/share/OVMF/OVMF_VARS.secboot.fd", |
| # "format": "raw" |
| # } |
| # }, |
| # "targets": [ |
| # { |
| # "architecture": "x86_64", |
| # "machines": [ |
| # "pc-q35-*" |
| # ] |
| # } |
| # ], |
| # "features": [ |
| # "acpi-s3", |
| # "amd-sev", |
| # "enrolled-keys", |
| # "requires-smm", |
| # "secure-boot", |
| # "verbose-dynamic" |
| # ], |
| # "tags": [ |
| # "-a IA32", |
| # "-a X64", |
| # "-p OvmfPkg/OvmfPkgIa32X64.dsc", |
| # "-t GCC48", |
| # "-b DEBUG", |
| # "-D SMM_REQUIRE", |
| # "-D SECURE_BOOT_ENABLE", |
| # "-D FD_SIZE_4MB" |
| # ] |
| # } |
| # |
| # { |
| # "description": "OVMF with SEV-ES support", |
| # "interface-types": [ |
| # "uefi" |
| # ], |
| # "mapping": { |
| # "device": "flash", |
| # "executable": { |
| # "filename": "/usr/share/OVMF/OVMF_CODE.fd", |
| # "format": "raw" |
| # }, |
| # "nvram-template": { |
| # "filename": "/usr/share/OVMF/OVMF_VARS.fd", |
| # "format": "raw" |
| # } |
| # }, |
| # "targets": [ |
| # { |
| # "architecture": "x86_64", |
| # "machines": [ |
| # "pc-q35-*" |
| # ] |
| # } |
| # ], |
| # "features": [ |
| # "acpi-s3", |
| # "amd-sev", |
| # "amd-sev-es", |
| # "verbose-dynamic" |
| # ], |
| # "tags": [ |
| # "-a X64", |
| # "-p OvmfPkg/OvmfPkgX64.dsc", |
| # "-t GCC48", |
| # "-b DEBUG", |
| # "-D FD_SIZE_4MB" |
| # ] |
| # } |
| # |
| # { |
| # "description": "UEFI firmware for ARM64 virtual machines", |
| # "interface-types": [ |
| # "uefi" |
| # ], |
| # "mapping": { |
| # "device": "flash", |
| # "executable": { |
| # "filename": "/usr/share/AAVMF/AAVMF_CODE.fd", |
| # "format": "raw" |
| # }, |
| # "nvram-template": { |
| # "filename": "/usr/share/AAVMF/AAVMF_VARS.fd", |
| # "format": "raw" |
| # } |
| # }, |
| # "targets": [ |
| # { |
| # "architecture": "aarch64", |
| # "machines": [ |
| # "virt-*" |
| # ] |
| # } |
| # ], |
| # "features": [ |
| # |
| # ], |
| # "tags": [ |
| # "-a AARCH64", |
| # "-p ArmVirtPkg/ArmVirtQemu.dsc", |
| # "-t GCC48", |
| # "-b DEBUG", |
| # "-D DEBUG_PRINT_ERROR_LEVEL=0x80000000" |
| # ] |
| # } |
| ## |
| { 'struct' : 'Firmware', |
| 'data' : { 'description' : 'str', |
| 'interface-types' : [ 'FirmwareOSInterface' ], |
| 'mapping' : 'FirmwareMapping', |
| 'targets' : [ 'FirmwareTarget' ], |
| 'features' : [ 'FirmwareFeature' ], |
| 'tags' : [ 'str' ] } } |
