External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-02-22 03:12:22 +00:00
Code Issues Packages Projects Releases Wiki Activity
libvirt/tests/qemufirmwaredata/usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json

28 lines
505 B
JSON
Raw Normal View History

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
{
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
"description": "OVMF with TDX support",
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 16:19:07 +02: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 16:19:07 +02:00
"enrolled-keys",
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
"intel-tdx",
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 16:19:07 +02:00
"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"
],
"tags": [
]
}
Reference in New Issue Copy Permalink