From nobody Fri Jan 9 08:55:43 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; 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 8.43.85.245 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=1766967307; cv=none; d=zohomail.com; s=zohoarc; b=K22/ldDPzUCFOzMWm6hFunSq/tPSJps4hiq4nbl0THJMylbpEi57ko2s6LFhmgAc89DlFQrwLi5Pn/FIlOkjSxX8BSHUOqPXtexOqLSgg/joNiGR4rH+ef1FN1MkF/PDLkmfrqXqI7Tj/dyJqIXPU9cY40sk/LPfQjTb9rYfO0k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1766967307; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Subject:Subject:To:To:Message-Id:Cc; bh=4BJu7lWytNJ7CHAepmy7tF7XCFQ4qf5iAomKRqPZjaQ=; b=cvsOpdX8mJkWQR04gPDbPyqUFO/NbyFMynaknCv9V8PIpm4tyevWb2QmTVEN9bYM21mp9/NQhnyPBISBMqU8xDze96Wqn5Yn3ustX5PBwCV5Kw+7D9oLfd4RYJcmdaDubjqiydtgsxbhJF614rvxS2jvKHI1MSo5A2/DPXdEkbM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 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 [8.43.85.245]) by mx.zohomail.com with SMTPS id 1766967307179889.2091538053036; Sun, 28 Dec 2025 16:15:07 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id 3FB6641A10; Sun, 28 Dec 2025 19:15:06 -0500 (EST) Received: from [172.19.199.83] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id C49A341B04; Sun, 28 Dec 2025 19:01:13 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 30A4C417F0; Sun, 28 Dec 2025 18:34:49 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.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 E97043F2B4 for ; Sun, 28 Dec 2025 18:34:46 -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-465-Yc3JbusINKiXOhUv0oQC7w-1; Sun, 28 Dec 2025 18:34:45 -0500 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 727581956046 for ; Sun, 28 Dec 2025 23:34:44 +0000 (UTC) Received: from harajuku.usersys.redhat.com.homenet.telecomitalia.it (unknown [10.45.224.19]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B341830001A8 for ; Sun, 28 Dec 2025 23:34:43 +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=-5.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766964886; 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: in-reply-to:in-reply-to:references:references; bh=4BJu7lWytNJ7CHAepmy7tF7XCFQ4qf5iAomKRqPZjaQ=; b=M61nOZqzWKQvVdplQRPMzueEgZu6ZsP/xLNkrLNLw8rABA2GcVYFEiNoMAcqXWH9mKp0Wq cUuqb/1ScnFizTvt8arQCAcwDPZzhET1GSfUr+Az2Lt6ZCMgjWDT2orvePFj3j3QsU2vOK fe7+WgjtSuJYHtCWdiCe9HH4IWk/YD8= X-MC-Unique: Yc3JbusINKiXOhUv0oQC7w-1 X-Mimecast-MFC-AGG-ID: Yc3JbusINKiXOhUv0oQC7w_1766964884 To: devel@lists.libvirt.org Subject: [PATCH 24/36] qemu_firmware: Simplify handling of legacy paths Date: Mon, 29 Dec 2025 00:34:00 +0100 Message-ID: <20251228233412.1709869-25-abologna@redhat.com> In-Reply-To: <20251228233412.1709869-1-abologna@redhat.com> References: <20251228233412.1709869-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: IEAtJos2O__bhZePAUZxTwPpGk4eWQR91Wsbu42DTx0_1766964884 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: YTV4EMZW3JU7XSANHMYLIZNOL2C66PRK X-Message-ID-Hash: YTV4EMZW3JU7XSANHMYLIZNOL2C66PRK X-MailFrom: abologna@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: Andrea Bolognani via Devel Reply-To: Andrea Bolognani X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1766967309251158500 Content-Type: text/plain; charset="utf-8"; x-default="true" Currently we're doing a weird dance to avoid overwriting the user-provided path to the NVRAM template, which might potentially be one we actually know about but just so happens not to be listed first. Explaining why we're doing things this way requires a fairly long comment. We can make things simpler: if the NVRAM template path is present in the domain XML, include it into the matching criteria. This is consistent with how we match firmware descriptors. Handling of format, both for the firmware executable and the NVRAM template, is improved too. Legacy paths were used before non-raw firmware builds existed, so we can set the format to raw unconditionally. Signed-off-by: Andrea Bolognani --- src/qemu/qemu_firmware.c | 65 +++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 35 deletions(-) diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 2b16d66818..a7bb8f7e45 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1653,6 +1653,7 @@ qemuFirmwareFillDomainLegacy(virQEMUDriver *driver, { g_autoptr(virQEMUDriverConfig) cfg =3D virQEMUDriverGetConfig(driver); virDomainLoaderDef *loader =3D def->os.loader; + virFirmware *theone =3D NULL; size_t i; =20 if (!loader) @@ -1681,6 +1682,13 @@ qemuFirmwareFillDomainLegacy(virQEMUDriver *driver, return 1; } =20 + if (loader->nvramTemplateFormat && + loader->nvramTemplateFormat !=3D VIR_STORAGE_FILE_RAW) { + VIR_DEBUG("Ignoring legacy entries for loader with nvram template = format '%s'", + virStorageFileFormatTypeToString(loader->nvramTemplateFo= rmat)); + return 1; + } + for (i =3D 0; i < cfg->nfirmwares; i++) { virFirmware *fw =3D cfg->firmwares[i]; =20 @@ -1690,47 +1698,34 @@ qemuFirmwareFillDomainLegacy(virQEMUDriver *driver, continue; } =20 - loader->type =3D VIR_DOMAIN_LOADER_TYPE_PFLASH; - loader->readonly =3D VIR_TRISTATE_BOOL_YES; - loader->format =3D VIR_STORAGE_FILE_RAW; - - /* Only use the default template path if one hasn't been - * provided by the user. Assume that the template is in 'raw' form= at. - * - * In addition to fully-custom templates, which are a valid - * use case, we could simply be in a situation where - * qemu.conf contains - * - * nvram =3D [ - * "/path/to/OVMF_CODE.secboot.fd:/path/to/OVMF_VARS.fd", - * "/path/to/OVMF_CODE.secboot.fd:/path/to/OVMF_VARS.secboot.f= d" - * ] - * - * and the domain has been configured as - * - * - * /path/to/OVMF_CODE= .secboot.fd - * - * - * - * In this case, the global default is to have Secure Boot - * disabled, but the domain configuration explicitly enables - * it, and we shouldn't overrule this choice */ - if (!loader->nvramTemplate) { - loader->nvramTemplate =3D g_strdup(cfg->firmwares[i]->nvram); - loader->nvramTemplateFormat =3D VIR_STORAGE_FILE_RAW; + if (loader->nvramTemplate && + !virFileComparePaths(fw->nvram, loader->nvramTemplate)) { + VIR_DEBUG("Not matching nvram template path '%s' for user prov= ided path '%s'", + fw->nvram, loader->nvramTemplate); + continue; } =20 - if (loader->nvramTemplateFormat =3D=3D VIR_STORAGE_FILE_NONE) - loader->nvramTemplateFormat =3D VIR_STORAGE_FILE_RAW; + theone =3D fw; + break; + } =20 - VIR_DEBUG("decided on firmware '%s' template '%s'", - loader->path, NULLSTR(loader->nvramTemplate)); + if (!theone) + return 1; =20 - return 0; + loader->type =3D VIR_DOMAIN_LOADER_TYPE_PFLASH; + loader->readonly =3D VIR_TRISTATE_BOOL_YES; + + loader->format =3D VIR_STORAGE_FILE_RAW; + loader->nvramTemplateFormat =3D VIR_STORAGE_FILE_RAW; + + if (!loader->nvramTemplate) { + loader->nvramTemplate =3D g_strdup(theone->nvram); } =20 - return 1; + VIR_DEBUG("decided on firmware '%s' template '%s'", + loader->path, loader->nvramTemplate); + + return 0; } =20 =20 --=20 2.52.0