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 :|