From nobody Sun Nov 24 00:15:23 2024 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; 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=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1730794046626672.9124801967563; Tue, 5 Nov 2024 00:07:26 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 7A1FF12F9; Tue, 5 Nov 2024 03:07:25 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 1778212CE; Tue, 5 Nov 2024 02:59:13 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 2358911A7; Tue, 5 Nov 2024 02:59:00 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id A9C1512F6 for ; Tue, 5 Nov 2024 02:58:33 -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-573-wPzpa_7sPuSg3KeofdtgHg-1; Tue, 05 Nov 2024 02:58:32 -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 7ABE71955D4B for ; Tue, 5 Nov 2024 07:58:31 +0000 (UTC) Received: from speedmetal.lan (unknown [10.45.242.2]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B42FF30001A6 for ; Tue, 5 Nov 2024 07:58:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730793513; 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=yxcgQHNJNo6O7RjWxaeQ4qFRO5vclbbvK8yYs5yZ8ao=; b=WE1U4ZpC+3GLuEKvGOF2iFL7dWM3bWRSHCB6TfarNCFQhIW0u7F50WcVZeLRSVJmNDOIQ0 Mt3pwwu+x0ikwPGlhSMkAbnbuVtZkJgKMBidpf4LA3VTyNCoDILVj6kDdUbKii/bdnK09X G2RFxijAMDIctwmCoadaahZWiRwzArg= X-MC-Unique: wPzpa_7sPuSg3KeofdtgHg-1 From: Peter Krempa To: devel@lists.libvirt.org Subject: [PATCH 13/13] qemu: process: Introduce setup of block-device backed NVRAM Date: Tue, 5 Nov 2024 08:58:11 +0100 Message-ID: <0672d5de2b81e54c02afcda820cced5668be8bfd.1730793407.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6E7EQLLT43QLJ6LDBY5B37ETHEPD2DB6 X-Message-ID-Hash: 6E7EQLLT43QLJ6LDBY5B37ETHEPD2DB6 X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1730794048886116600 Content-Type: text/plain; charset="utf-8" In case when a management application will require to store the nvram in a block device instead of a file libvirt needs to be able to set up the block device. This patch introduces support for setting up the block device by using 'qemu-img convert' to produce a qcow2-formatted block device. The use of 'qcow2' is made mandatory as the UEFI firmware requires that the NVRAM image has the exact expected size, which is almost impossible with block devices. 'qcow2' also allows libvirt to detect wheher the block device is formatted allowing file-like semantics. Signed-off-by: Peter Krempa --- src/qemu/qemu_process.c | 74 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 66 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 7fbf18ec10..c25929da90 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -101,6 +101,7 @@ #include "virutil.h" #include "storage_source.h" #include "backup_conf.h" +#include "storage_file_probe.h" #include "logging/log_manager.h" #include "logging/log_protocol.h" @@ -4583,6 +4584,70 @@ qemuPrepareNVRAMHelper(int dstFD, } +static int +qemuPrepareNVRAMBlock(virDomainObj *vm, + bool reset_nvram) +{ + virDomainLoaderDef *loader =3D vm->def->os.loader; + g_autoptr(virCommand) qemuimg =3D NULL; + const char *templateFormatStr =3D "raw"; + + if (!virFileExists(loader->nvram->path)) { + virReportError(VIR_ERR_INVALID_ARG, + _("'block' nvram backing device '%1$s' doesn't exis= t"), + loader->nvram->path); + return -1; + } + + if (!reset_nvram) { + int format; + + if (loader->nvram->format =3D=3D VIR_STORAGE_FILE_RAW) { + /* For 'raw' image libvirt can't check if the image is correct= */ + return 0; + } + + if ((format =3D virStorageFileProbeFormat(loader->nvram->path, 0, = 0)) < 0) + return -1; + + /* If we find a qcow2 image assume it's correct */ + if (format =3D=3D VIR_STORAGE_FILE_QCOW2) + return 0; + } + + /* The PFLASH device backing the NVRAM must have the exact size the + * firmware expects. This is almost impossible to achieve using a block + * device. Avoid headaches -> force users to use qcow2 which can + * restrict the size if libvirt is to format the image. */ + if (loader->nvram->format !=3D VIR_STORAGE_FILE_QCOW2) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("only 'qcow2' formatted 'block' nvram backing can= be formatted")); + return -1; + } + + if (!loader->nvramTemplate) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("unable to find nvram template image")); + return -1; + } + + if (loader->nvramTemplateFormat !=3D VIR_STORAGE_FILE_NONE) + templateFormatStr =3D virStorageFileFormatTypeToString(loader->nvr= amTemplateFormat); + + qemuimg =3D virCommandNewArgList("qemu-img", "convert", + "-f", templateFormatStr, + "-O", "qcow2", + loader->nvramTemplate, + loader->nvram->path, + NULL); + + if (virCommandRun(qemuimg, NULL) < 0) + return -1; + + return 0; +} + + static int qemuPrepareNVRAMFile(virDomainObj *vm, bool reset_nvram) @@ -4646,14 +4711,7 @@ qemuPrepareNVRAM(virDomainObj *vm, return qemuPrepareNVRAMFile(vm, reset_nvram); case VIR_STORAGE_TYPE_BLOCK: - /* virFileRewrite() would overwrite the device node-file/symlink r= ather than - * just write the data to it, thus block-device nvram is not yet s= upported */ - if (virFileExists(loader->nvram->path) && !reset_nvram) - return 0; - - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("creation or formatting of nvram type=3D'block' i= s not supported")); - return -1; + return qemuPrepareNVRAMBlock(vm, reset_nvram); case VIR_STORAGE_TYPE_DIR: case VIR_STORAGE_TYPE_NETWORK: --=20 2.47.0