2022-06-09 16:02:19 +03:00
<domain type= 'kvm' >
2023-02-08 21:28:05 +03:00
<name > guest</name>
2022-06-09 16:02:19 +03:00
<uuid > 63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
2023-02-08 21:28:05 +03:00
<memory unit= 'KiB' > 1048576</memory>
<currentMemory unit= 'KiB' > 1048576</currentMemory>
2022-06-09 16:02:19 +03:00
<vcpu placement= 'static' > 1</vcpu>
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
<os >
2022-06-09 16:02:19 +03:00
<type arch= 'x86_64' machine= 'pc-q35-4.0' > hvm</type>
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
<loader readonly= 'yes' type= 'pflash' > /usr/share/OVMF/OVMF_CODE.fd</loader>
<nvram template= '/usr/share/OVMF/OVMF_VARS.fd' > /var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
2022-06-09 16:02:19 +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' />
2023-01-20 13:22:22 +03:00
<watchdog model= 'itco' action= 'reset' />
2022-06-09 16:02:19 +03:00
<memballoon model= 'none' />
</devices>
</domain>
