shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-02-03 17:47:15 +03:00
Code Releases Activity
libvirt/tests/qemuxml2argvdata/firmware-auto-efi-loader-insecure.xml

19 lines
479 B
XML
Raw Normal View History

conf: Validate firmware configuration more thoroughly Generally speaking, when firmware autoselection is in use we don't want any information to be provided manually. There are two exceptions: * we still want the path to the NVRAM file to be customizable; * using <loader secure='yes'/> was how you would ask for a firmware that implements the Secure Boot feature in the original approach to firmware autoselection, so we want to keep that working. Anything else should result in a descriptive error. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-06-15 12:00:58 +02:00
<domain type='kvm'>
tests: Unify input files for firmware tests Most of the differences, such as those in the domain name or amount of memory, are fairly harmless, but they still make it more cumbersome than necessary to directly compare different input (and output) files. More importantly, the use of unversioned machine types in some of the test cases results in the descriptor-based autoselection logic being effectively skipped, because the compatible machine types as listed in them are only the versioned variants. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 19:28:05 +01:00
<name>guest</name>
conf: Validate firmware configuration more thoroughly Generally speaking, when firmware autoselection is in use we don't want any information to be provided manually. There are two exceptions: * we still want the path to the NVRAM file to be customizable; * using <loader secure='yes'/> was how you would ask for a firmware that implements the Secure Boot feature in the original approach to firmware autoselection, so we want to keep that working. Anything else should result in a descriptive error. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-06-15 12:00:58 +02:00
<uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
tests: Unify input files for firmware tests Most of the differences, such as those in the domain name or amount of memory, are fairly harmless, but they still make it more cumbersome than necessary to directly compare different input (and output) files. More importantly, the use of unversioned machine types in some of the test cases results in the descriptor-based autoselection logic being effectively skipped, because the compatible machine types as listed in them are only the versioned variants. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 19:28:05 +01:00
<memory unit='KiB'>1048576</memory>
conf: Validate firmware configuration more thoroughly Generally speaking, when firmware autoselection is in use we don't want any information to be provided manually. There are two exceptions: * we still want the path to the NVRAM file to be customizable; * using <loader secure='yes'/> was how you would ask for a firmware that implements the Secure Boot feature in the original approach to firmware autoselection, so we want to keep that working. Anything else should result in a descriptive error. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-06-15 12:00:58 +02:00
<vcpu placement='static'>1</vcpu>
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
<loader secure='no'/>
</os>
<features>
<acpi/>
</features>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<controller type='usb' model='none'/>
<memballoon model='none'/>
</devices>
</domain>
Copy Permalink