On Wed, Feb 18, 2026 at 01:05:47PM +0100, Andrea Bolognani via Devel wrote:
> Currently we only look at the value for the stateless attribute
> itself when matching, but the <nvram> element being included in
> the input XML is likewise a clear sign that a stateless firmware
> build will not satisfy the user's requirements.
>
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
> src/qemu/qemu_firmware.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
> index 1ecbee0c96..d1eba31103 100644
> --- a/src/qemu/qemu_firmware.c
> +++ b/src/qemu/qemu_firmware.c
> @@ -1289,13 +1289,19 @@ qemuFirmwareMatchDomain(const virDomainDef *def,
> /* Explicit requests for either a stateless or stateful
> * firmware should be fulfilled, but if no preference is
> * provided either one is fine as long as the other match
> - * criteria are satisfied */
> + * criteria are satisfied. NVRAM implies stateful */
> if (loader &&
> loader->stateless == VIR_TRISTATE_BOOL_NO &&
> flash->mode == QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
> VIR_DEBUG("Discarding stateless loader");
> return false;
> }
> + if (loader &&
> + loader->nvram &&
> + flash->mode == QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
> + VIR_DEBUG("Discarding stateless loader");
> + return false;
> + }
That feels like a non-sensical scenario for a firmware descriptor.
In a few other cases we VIR_WARN about nonsense descriptor settings,
so perhaps here too ?
> if (loader &&
> loader->stateless == VIR_TRISTATE_BOOL_YES &&
> flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
> --
> 2.53.0
>
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|