Hi All, While investigating an internal bug report, we noticed that a minimal firmware auto-selection configuration along with SEV* fails to find a match. E.g. the following config <domain type="kvm"> <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <boot dev="hd"/> </os> <launchSecurity type="sev"> <policy>0x07</policy> </launchSecurity> ... </domain> Fails with "Unable to find 'efi' firmware that is compatible with the current configuration". A firmware that should match has the following json description { "description": "UEFI firmware for x86_64, with AMD SEV", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "acpi-s4", "amd-sev", "amd-sev-es", "amd-sev-snp", "verbose-dynamic" ], "tags": [ ] } Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend the above config with <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <loader stateless="yes"/> <boot dev="hd"/> </os> Being unfamiliar with the firmware auto-selection code, I tried the below naive hack, which only led to test failures and the subsequent runtime error "unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin". Should auto-selection work with the minimal config, or is it expected that user also specify a stateless firmware?

On 4/24/25 04:59, Daniel P. Berrangé wrote: > On Mon, Apr 21, 2025 at 01:38:35PM -0600, Jim Fehlig via Devel wrote: >> Hi All, >> >> While investigating an internal bug report, we noticed that a minimal >> firmware auto-selection configuration along with SEV* fails to find a match. >> E.g. the following config >> >> <domain type="kvm"> >>    <os firmware="efi"> >>      <type arch="x86_64" machine="q35">hvm</type> >>      <boot dev="hd"/> >>    </os> >>    <launchSecurity type="sev"> >>      <policy>0x07</policy> >>    </launchSecurity> >> ... >> </domain> >> >> Fails with "Unable to find 'efi' firmware that is compatible with the >> current configuration". A firmware that should match has the following json >> description >> >> { >>      "description": "UEFI firmware for x86_64, with AMD SEV", >>      "interface-types": [ >>          "uefi" >>      ], >>      "mapping": { >>          "device": "flash", >>     "mode": "stateless", >>          "executable": { >>              "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", >>              "format": "raw" >>          } >>      }, >>      "targets": [ >>          { >>              "architecture": "x86_64", >>              "machines": [ >>                  "pc-q35-*" >>              ] >>          } >>      ], >>      "features": [ >>          "acpi-s4", >>     "amd-sev", >>     "amd-sev-es", >>     "amd-sev-snp", >>          "verbose-dynamic" >>      ], >>      "tags": [ >> >>      ] >> } >> >> Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend >> the above config with >> >>    <os firmware="efi"> >>      <type arch="x86_64" machine="q35">hvm</type> >>      <loader stateless="yes"/> >>      <boot dev="hd"/> >>    </os> >> >> Being unfamiliar with the firmware auto-selection code, I tried the below >> naive hack, which only led to test failures and the subsequent runtime error >> "unable to find any master var store for loader: >> /usr/share/qemu/ovmf-x86_64-sev.bin". Should auto-selection work with the >> minimal config, or is it expected that user also specify a stateless >> firmware?

> > I don't have any SEV/SNP installation available to test with current, > but on Fedora/RHEL, AFAIK, we successfully install with > > virt-install  \ > --name snp  \ > --launchSecurity sev-snp,policy=0x30000  \ > --machine q35 > --boot uefi I see the same failure when using '--boot uefi' or '--boot firmware=efi' ERROR    operation failed: Unable to find 'efi' firmware that is compatible with the current configuration Works fine with '--boot firmware=efi,loader.stateless=yes'. > which will NOT result in 'stateless' attribute being set and our > firwmare descriptors match what you show above. Nod. The rawhide descriptor '60-edk2-ovmf-x64-amdsev.json' is nearly identical to the one I posted, with exception of the missing acpi-s4 feature. But that shouldn't be there anyhow. It's a bug that has since been fixed in the openSUSE descriptor. Regards, Jim

On 5/13/25 14:25, Jim Fehlig wrote: > On 4/24/25 14:18, Jim Fehlig wrote: > > On 4/24/25 04:59, Daniel P. Berrangé wrote: > > > On Mon, Apr 21, 2025 at 01:38:35PM -0600, Jim Fehlig via Devel wrote: > > > > Hi All, > > > > > > > > While investigating an internal bug report, we noticed that a minimal > > > > firmware auto-selection configuration along with SEV* fails to find a match. > > > > E.g. the following config > > > > > > > > <domain type="kvm"> > > > >    <os firmware="efi"> > > > >      <type arch="x86_64" machine="q35">hvm</type> > > > >      <boot dev="hd"/> > > > >    </os> > > > >    <launchSecurity type="sev"> > > > >      <policy>0x07</policy> > > > >    </launchSecurity> > > > > ... > > > > </domain> > > > > > > > > Fails with "Unable to find 'efi' firmware that is compatible with the > > > > current configuration". A firmware that should match has the following json > > > > description > > > > > > > > { > > > >      "description": "UEFI firmware for x86_64, with AMD SEV", > > > >      "interface-types": [ > > > >          "uefi" > > > >      ], > > > >      "mapping": { > > > >          "device": "flash", > > > >     "mode": "stateless", > > > >          "executable": { > > > >              "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", > > > >              "format": "raw" > > > >          } > > > >      }, > > > >      "targets": [ > > > >          { > > > >              "architecture": "x86_64", > > > >              "machines": [ > > > >                  "pc-q35-*" > > > >              ] > > > >          } > > > >      ], > > > >      "features": [ > > > >          "acpi-s4", > > > >     "amd-sev", > > > >     "amd-sev-es", > > > >     "amd-sev-snp", > > > >          "verbose-dynamic" > > > >      ], > > > >      "tags": [ > > > > > > > >      ] > > > > } > > > > > > > > Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend > > > > the above config with > > > > > > > >    <os firmware="efi"> > > > >      <type arch="x86_64" machine="q35">hvm</type> > > > >      <loader stateless="yes"/> > > > >      <boot dev="hd"/> > > > >    </os> > > > > > > > > Being unfamiliar with the firmware auto-selection code, I tried the below > > > > naive hack, which only led to test failures and the subsequent runtime error > > > > "unable to find any master var store for loader: > > > > /usr/share/qemu/ovmf-x86_64-sev.bin". Should auto-selection work with the > > > > minimal config, or is it expected that user also specify a stateless > > > > firmware? > > Andrea, > > Having spent a fair bit of time in the firmware auto-selection code, > perhaps you have an opinion about this? Sorry to keep nagging about this, but I still see the issue with latest git master using a json descriptor identical to the latest Fedora one. When omitting the 'stateless' attribute, autoselection fails with operation failed: Unable to find 'efi' firmware that is compatible with the current configuration With debug enabled, I can see the firmware is not even considered since it's not "split" 2025-07-29 21:02:05.517+0000: 32187: debug : qemuFirmwareMatchDomain:1310 : Discarding loader without split flash I would need to install Fedora and verify myself, but I'd be surprised if it didn't encounter the same issue. Without the 'stateless' attribute, the following test would fail https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_firmware.c... executing the else condition, and failing similarly since the firmware is not split.