shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-06 17:17:56 +03:00
Code Releases Activity
212b7d8e28
libvirt/tests/qemuxmlconfdata/firmware-manual-efi-no-secboot.x86_64-latest.xml

41 lines
1.4 KiB
XML
Raw Normal View History

tests: Add more tests for manual Secure Boot configuration These cover the same scenarios as the matching test cases for autoselection. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 21:39:06 +03:00
<domain type='qemu'>
<name>guest</name>
<uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>1</vcpu>
qemu: Automatically add firmware type/features information Even when the user is not taking advantage of firmware autoselection and instead manually providing all the necessary information, in most cases they're still going to use firmware builds that are provided by the OS vendor, are installed in standard paths and come with a corresponding firmware descriptor. Similarly, even when the user is not guiding the autoselection process by specifying the desired status of certain features and instead is relying on the system-level descriptor priority being set up correctly, libvirt will still ultimately decide to use a specific descriptor, which includes information about the firmware's features. In both these cases, take the additional information that were obtained from the firmware descriptor and reflect them back into the domain XML, where they can be conveniently inspected by the user and management applications alike. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 19:53:02 +03:00
<os firmware='efi'>
tests: Add more tests for manual Secure Boot configuration These cover the same scenarios as the matching test cases for autoselection. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 21:39:06 +03:00
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
qemu: Automatically add firmware type/features information Even when the user is not taking advantage of firmware autoselection and instead manually providing all the necessary information, in most cases they're still going to use firmware builds that are provided by the OS vendor, are installed in standard paths and come with a corresponding firmware descriptor. Similarly, even when the user is not guiding the autoselection process by specifying the desired status of certain features and instead is relying on the system-level descriptor priority being set up correctly, libvirt will still ultimately decide to use a specific descriptor, which includes information about the firmware's features. In both these cases, take the additional information that were obtained from the firmware descriptor and reflect them back into the domain XML, where they can be conveniently inspected by the user and management applications alike. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 19:53:02 +03:00
<firmware>
<feature enabled='no' name='enrolled-keys'/>
<feature enabled='no' name='secure-boot'/>
</firmware>
conf: Always format firmware image format The code historically skipped the 'format' field for 'raw' images as we didn't output it when no format support was present. Stop misleading and output the format also for 'raw' images. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-08-26 16:37:35 +03:00
<loader readonly='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
conf: domain: Output 'format' attribute of '<nvram>' also for' raw images As the 'format' field is meant to carry the format of the nvram image we should output it even when the image is 'raw'. Currently this is not a problem but later patches will allow mismatch between the nvram format and loader format (as nothing really technically requires them to be the same and this then could become problem). Modify the condition and update tests. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-08-22 13:12:10 +03:00
<nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd' templateFormat='raw' format='raw'>/path/to/guest_VARS.fd</nvram>
tests: Add more tests for manual Secure Boot configuration These cover the same scenarios as the matching test cases for autoselection. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 21:39:06 +03:00
<boot dev='hd'/>
</os>
<features>
<acpi/>
</features>
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>qemu64</model>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<controller type='usb' index='0' model='none'/>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pcie-root'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<audio id='1' type='none'/>
<watchdog model='itco' action='reset'/>
<memballoon model='none'/>
</devices>
</domain>
Copy Permalink