libvirt/tests/qemuxml2argvdata/firmware-manual-efi-secure.xml

<domain type='qemu'>
  <name>test-bios</name>
  <uuid>362d1fc1-df7d-193e-5c18-49a71bd1da66</uuid>
  <memory unit='KiB'>1048576</memory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='q35'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/some/user/nvram/path/guest_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <smm state='on'/>
  </features>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <controller type='usb' model='none'/>
    <memballoon model='none'/>
  </devices>
</domain>
Introduce @secure attribute to os loader element This element will control secure boot implemented by some firmwares. If the firmware used in <loader/> does support the feature we must tell it to the underlying hypervisor. However, we can't know whether loader does support it or not just by looking at the file. Therefore we have to have an attribute to the element where users can tell us whether the firmware is secure boot enabled or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> 2016-07-13 07:22:51 +00:00			`<domain type='qemu'>`
			`<name>test-bios</name>`
			`<uuid>362d1fc1-df7d-193e-5c18-49a71bd1da66</uuid>`
			`<memory unit='KiB'>1048576</memory>`
			`<vcpu placement='static'>1</vcpu>`
			`<os>`
tests: qemuxml2argvdata: Remove specific q35 machine types from fake-caps tests Use q35 instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> 2022-01-05 09:19:36 +00:00			`<type arch='x86_64' machine='q35'>hvm</type>`
Introduce @secure attribute to os loader element This element will control secure boot implemented by some firmwares. If the firmware used in <loader/> does support the feature we must tell it to the underlying hypervisor. However, we can't know whether loader does support it or not just by looking at the file. Therefore we have to have an attribute to the element where users can tell us whether the firmware is secure boot enabled or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> 2016-07-13 07:22:51 +00:00			`<loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>`
tests: don't use auto-generated NVRAM path in tests By using the auto-generated NVRAM path in test data files, we won't see bugs where a user specified path gets accidentally overwritten by a post-parse callback, or VM startup. For example, this caused us to miss the bug fixed by: commit 24adb6c7a6cbd8ce5f9de67e6af5d89e0e57c270 Author: Michal Prívozník <mprivozn@redhat.com> Date: Wed Feb 23 08:50:44 2022 +0100 qemu: Don't regenerate NVRAM path if parsed from domain XML Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> 2022-02-23 12:45:51 +00:00			`<nvram>/some/user/nvram/path/guest_VARS.fd</nvram>`
Introduce @secure attribute to os loader element This element will control secure boot implemented by some firmwares. If the firmware used in <loader/> does support the feature we must tell it to the underlying hypervisor. However, we can't know whether loader does support it or not just by looking at the file. Therefore we have to have an attribute to the element where users can tell us whether the firmware is secure boot enabled or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> 2016-07-13 07:22:51 +00:00			`</os>`
			`<features>`
			`<acpi/>`
			`<smm state='on'/>`
			`</features>`
			`<devices>`
tests: unify qemu binary paths for all qemu related tests Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: Pavel Hrdina <phrdina@redhat.com> 2017-04-06 16:19:48 +00:00			`<emulator>/usr/bin/qemu-system-x86_64</emulator>`
tests: Use minimal hardware for firmware tests When testing firmware selection, we don't really care about any of the hardware assigned to the VM, and in fact it's better to keep it as minimal as possible to make sure that the focus remains on the firmware bits. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> 2022-06-09 13:02:19 +00:00			`<controller type='usb' model='none'/>`
			`<memballoon model='none'/>`
Introduce @secure attribute to os loader element This element will control secure boot implemented by some firmwares. If the firmware used in <loader/> does support the feature we must tell it to the underlying hypervisor. However, we can't know whether loader does support it or not just by looking at the file. Therefore we have to have an attribute to the element where users can tell us whether the firmware is secure boot enabled or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> 2016-07-13 07:22:51 +00:00			`</devices>`
			`</domain>`