shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
f9ad302335
libvirt/tests/qemuxml2xmloutdata/firmware-manual-efi-acpi-aarch64.aarch64-latest.xml

36 lines
1.1 KiB
XML
Raw Normal View History

tests: Enable qemuxml2xml for more firmware tests Some of the test cases had only been added to the xml2argv test program and not to the xml2xml one. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 21:15:55 +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: Enable qemuxml2xml for more firmware tests Some of the test cases had only been added to the xml2argv test program and not to the xml2xml one. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 21:15:55 +03:00
<type arch='aarch64' machine='virt-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>
tests: Enable qemuxml2xml for more firmware tests Some of the test cases had only been added to the xml2argv test program and not to the xml2xml one. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 21:15:55 +03:00
<loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader>
qemu: Move firmware selection from startup to postparse Currently, firmware selection is performed as part of the domain startup process. This mostly works fine, but there's a significant downside to this approach: since the process is affected by factors outside of libvirt's control, specifically the contents of the various JSON firmware descriptors and their names, it's pretty much impossible to guarantee that the outcome is always going to be the same. It would only take an edk2 update, or a change made by the local admin, to render a domain unbootable or downgrade its boot security. To avoid this, move firmware selection to the postparse phase. This way it will only be performed once, when the domain is first defined; subsequent boots will not need to go through the process again, as all the paths that were picked during firmware selection are recorded in the domain XML. Care is taken to ensure that existing domains are handled correctly, even if their firmware configuration can't be successfully resolved. Failure to complete the firmware selection process is only considered fatal when defining a new domain; in all other cases the error will be reported during startup, as is already the case today. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-24 19:01:48 +03:00
<nvram template='/usr/share/AAVMF/AAVMF_VARS.fd'>/path/to/guest_VARS.fd</nvram>
tests: Enable qemuxml2xml for more firmware tests Some of the test cases had only been added to the xml2argv test program and not to the xml2xml one. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-02-08 21:15:55 +03:00
<boot dev='hd'/>
</os>
<features>
<acpi/>
<gic version='2'/>
</features>
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>cortex-a15</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-aarch64</emulator>
<controller type='usb' index='0' model='none'/>
<controller type='pci' index='0' model='pcie-root'/>
<audio id='1' type='none'/>
<memballoon model='none'/>
</devices>
</domain>
Copy Permalink