From nobody Sun Nov 15 00:27:54 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1794502520; cv=none; d=zohomail.com; s=zohoarc; b=kkhPw+9WEOpJcC6RuOy1lpmBZEZg5r48zESVyFzJmW4s72HUuM9xjXIZAfv7PrbalbOmDNvi51uteT9ptyfedvgQB0FTrLfQ7afgYyZJs9ZOZ/aOHzcFAA79aCgJv1TlsaUpHesM/uXDGIQwphMqPkUOr7O7fJeZiZ6ItuYU1FE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1794502520; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=MHPjDCAxk8yJaPL559dk+iMb7I+u5OQClMIhnkeMmqI=; b=gHQdIDqbF3OVLqYOsjdedMphXmnDuLhG+whQsZbeQZxlKNKA6uiuN92QLMaew9I+bvMGsSPF2Z9qGjwYvNo8tD8GIMFeJCNEhky5TczUKJnaiPz4OaJ2aRmCpvJ779rxv9mZXxuIKlxgfFCWloEIXVcHQA/CFAQPiyjR6/RyyJI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1794502520790694.1841705899584; Thu, 12 Nov 2026 08:55:20 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id 2836341B0B; Thu, 12 Nov 2026 11:55:18 -0500 (EST) Received: from [172.19.199.22] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 9191241BF3; Thu, 12 Nov 2026 11:54:26 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 233713F304; Thu, 12 Nov 2026 11:54:17 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 305D93F289 for ; Thu, 12 Nov 2026 11:54:16 -0500 (EST) Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-654-hjnpUhhiMmO4LNx0-l58_Q-1; Thu, 12 Nov 2026 11:54:13 -0500 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EB99F1956055 for ; Thu, 12 Nov 2026 16:54:11 +0000 (UTC) Received: from speedmetal.openshiftapps.com (unknown [10.44.22.3]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 33000195608B for ; Thu, 12 Nov 2026 16:54:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_PASS autolearn=no autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1794502455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=MHPjDCAxk8yJaPL559dk+iMb7I+u5OQClMIhnkeMmqI=; b=iZmTkHvrgts4RhvCiB20KO8HXFNoQOsRb6yTLHQKO7ZQ9B/Ub/kuRqdqb8DaZvTEL1AuzP IHy5m741A+y+zWrTh5yQNVtzVluk9bfsxabxNIgkH1/IlWqqp1+bgMv3epOvrA3sTOA64X lsczcYXNsM5exmX+PccN7wsSAUJUCnA= X-MC-Unique: hjnpUhhiMmO4LNx0-l58_Q-1 X-Mimecast-MFC-AGG-ID: hjnpUhhiMmO4LNx0-l58_Q_1794502452 To: devel@lists.libvirt.org Subject: [PATCH] qemuPrepareNVRAMFile: Check NVRAM image format conversion only when it needs to be created Date: Thu, 12 Nov 2026 17:54:09 +0100 Message-ID: <71eda3fce1414625436099f887a12ac24d1ff8e9.1794502449.git.pkrempa@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 0l6hhPkG_CIZK2U6nlvlD4m59sFfIFIrCQ1CmMlmG9Q_1794502452 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: TGIVN7EKP4TR74OEVPHCUSHJIP6PDW2C X-Message-ID-Hash: TGIVN7EKP4TR74OEVPHCUSHJIP6PDW2C X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1794502521847158500 Content-Type: text/plain; charset="utf-8" From: Peter Krempa Commit 41fe1199bbad4ab9cc refactored 'qemuPrepareNVRAMFile' by splitting out checks which weren't relevant for the implementation of the alternative way to store UEFI variable data in the JSON file. By doing so the commit moved the check which disallows NVRAM configs where the user would ask for conversion of the template to another format *before* it's checked if a NVRAM image even needs to be populated. This means that any configs where the user converted their NVRAM image to a different format than the template which were previously working now start complaining that format conversion is not supported. Fix this by duplicating the logic that is used to determine if the image will be created. The existing logic can be now simplified because the caller ensures that 'loader' and 'loader->nvram' are non-NULL. Fixes: 41fe1199bbad4ab9cc4bda078571cd7bc5897d44 Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 3f1960f314..dec4a0e9c6 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5018,7 +5018,7 @@ qemuPrepareNVRAMFile(virQEMUDriver *driver, { /* If 'nvramTemplateFormat' is empty it means that it's a user-provided * template which we couldn't verify. Assume the user knows what they'= re doing */ - if (loader && loader->nvram && + if ((!virFileExists(loader->nvram->path) || reset_nvram) && loader->nvramTemplateFormat !=3D VIR_STORAGE_FILE_NONE && loader->nvram->format !=3D loader->nvramTemplateFormat) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", --=20 2.56.0