libvirt/tests/qemufirmwaredata/out/usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json

{
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "mode": "stateless",
        "executable": {
            "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd",
            "format": "raw"
        }
    },
    "targets": [
        {
            "architecture": "x86_64",
            "machines": [
                "pc-q35-*"
            ]
        }
    ],
    "features": [
        "amd-sev",
        "amd-sev-es",
        "amd-sev-snp",
        "verbose-dynamic"
    ]
}
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> 2022-02-03 13:43:18 +00:00			`{`
			`"interface-types": [`
			`"uefi"`
			`],`
			`"mapping": {`
			`"device": "flash",`
			`"mode": "stateless",`
			`"executable": {`
tests: Update firmware descriptor files These are imported from Fedora 38's edk2 package. The files that are being replaced date back to RHEL 7 and no longer represent what libvirt is likely to encounter on an actual production system. Notably, the paths have all changed, with both x86_64 and aarch64 builds now living under /usr/share/edk2 and the AAVMF name being having been phased out. Additionally, the 4MB qcow2 format builds have been introduced on x86_64 and given high priority, effectively making qcow2 the default format across architectures. The impact of these changes on the test suite is, predictably, quite severe. For the cases where paths to firmware files were explicitly provided as part of the input, they have been adjusted so that the modern paths are used instead of the legacy ones. Other than that, input files have been left untouched. The following expected changes can be seen in output files: * where qcow2 firmware was used on x86_64, Secure Boot support is now enabled; * all ABI_UPDATE test cases for x86_64 now use qcow2 formatted firmware; * test cases where legacy paths were manually provided no longer get additional information about the firmware added to the output XML. Some of the changes described above highlight why, in order to guarantee a stable guest ABI over time and regardless of changes to the host's configuration, it was necessary to move firmware selection from VM startup time to VM creation time. In a few cases, updating the firmware descriptors changes the behavior in a way that's undesired and uncovers latent bugs in libvirt: * firmware-manual-efi-secboot-legacy-paths ends up with Secure Boot disabled, despite the input XML specifically requesting it to be enabled; * firmware-manual-efi-rw-modern-paths loses the loader.readonly=no part of the configuration and starts using an NVRAM file; * firmware-manual-efi-nvram-template-nonstandard starts failing altogether with a fairly obscure error message. We're going to address all these issues with upcoming changes. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> 2023-05-11 18:29:17 +02:00			`"filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd",`
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> 2022-02-03 13:43:18 +00:00			`"format": "raw"`
			`}`
			`},`
			`"targets": [`
			`{`
			`"architecture": "x86_64",`
			`"machines": [`
			`"pc-q35-*"`
			`]`
			`}`
			`],`
			`"features": [`
			`"amd-sev",`
			`"amd-sev-es",`
qemu_firmware: Pick the right firmware for SEV-SNP guests The firmware descriptors have 'amd-sev-snp` feature which describes whether firmware is suitable for SEV-SNP guests. Provide necessary implementation to detect the feature and pick the right firmware if guest is SEV-SNP enabled. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 2024-06-13 14:35:57 +02:00			`"amd-sev-snp",`
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> 2022-02-03 13:43:18 +00:00			`"verbose-dynamic"`
			`]`
			`}`