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

{
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "memory",
        "filename": "/usr/share/edk2/ovmf/OVMF.inteltdx.secboot.fd"
    },
    "targets": [
        {
            "architecture": "x86_64",
            "machines": [
                "pc-q35-*"
            ]
        }
    ],
    "features": [
        "enrolled-keys",
        "secure-boot",
        "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": {`
tests: Update firmware descriptors Sync with the edk2-20240524-4.fc39 package from Fedora. The only notable change is that the inteltdx variant now declares support for Secure Boot and is a ROM image instead of a stateless pflash one. The latter causes it to be considered eligible for the configuration described by the firmware-auto-efi-rw test cases, which now passes instead of failing. Of course that doesn't make any sense, because a ROM image by definition cannot be read/write. So this indicates the presence of a bug in our firmware selection algorithm, which we're going to address with an upcoming commit. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2024-07-05 14:19:07 +00:00			`"device": "memory",`
			`"filename": "/usr/share/edk2/ovmf/OVMF.inteltdx.secboot.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			`},`
			`"targets": [`
			`{`
			`"architecture": "x86_64",`
			`"machines": [`
			`"pc-q35-*"`
			`]`
			`}`
			`],`
			`"features": [`
tests: Update firmware descriptors Sync with the edk2-20240524-4.fc39 package from Fedora. The only notable change is that the inteltdx variant now declares support for Secure Boot and is a ROM image instead of a stateless pflash one. The latter causes it to be considered eligible for the configuration described by the firmware-auto-efi-rw test cases, which now passes instead of failing. Of course that doesn't make any sense, because a ROM image by definition cannot be read/write. So this indicates the presence of a bug in our firmware selection algorithm, which we're going to address with an upcoming commit. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2024-07-05 14:19:07 +00:00			`"enrolled-keys",`
			`"secure-boot",`
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"`
			`]`
			`}`