From nobody Thu Nov 28 10:45:59 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1692804989; cv=none; d=zohomail.com; s=zohoarc; b=WvFdoeHKezwcnGVb9/WdAfEze4xOMkPNEgJGf6W+hIvpIUD33bSEtpvm3OY7aDvuRs1kH0ViytXpCD789vaSsZphZX+DUFNni9+RmsBcxPIL4L5f7A6eRDZywyV9gPwINvXq5K0rMOxFqhOYQHmruSrM4+Hh6pIBr9QNbBWs7ns= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1692804989; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=VO47LSVQYys4ca0LVUTtRTIQSZy6ad56mDKp1WS/7KU=; b=j6P7v8CfARHdRj+rmoQnNWqY7eTVjnpOtIlkxAGdhuQ22Jj1p+gy03Sq5mxjsdXI4W89fuEw38usM4fCY73DTe/tx2MOJR/vIQnkx50Zn0iUVm6tc+oj/b5gHY8SAirztyeQ63dmrOmmye4Ord0C1gQ2+m+FeUKwz2uAZvxCFR8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1692804989725304.89009330263104; Wed, 23 Aug 2023 08:36:29 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYpsk-000216-95; Wed, 23 Aug 2023 11:34:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qYpsP-0001wD-En for qemu-devel@nongnu.org; Wed, 23 Aug 2023 11:34:33 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qYpsN-0007z1-Cr for qemu-devel@nongnu.org; Wed, 23 Aug 2023 11:34:33 -0400 Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-488-XbPsutRfN1yD8hnyzFsqkg-1; Wed, 23 Aug 2023 11:34:25 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B70F73C0FC92; Wed, 23 Aug 2023 15:34:24 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.193.128]) by smtp.corp.redhat.com (Postfix) with ESMTP id F2BB91121319; Wed, 23 Aug 2023 15:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692804870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VO47LSVQYys4ca0LVUTtRTIQSZy6ad56mDKp1WS/7KU=; b=EHxba6ynMGLPI4MtN53qfRPekc1x3bNrVMcVAYXUAvVaY0z6l7Zkhu2IbY02Iw+yf3WAiY 7LA6P6YBpUHWY5PWNRlAA/T3GSUI+3m6rGUz9Ec1s1cYP1TBLojiVgeMWWWo2gETzO9n8i EMl2QrdTCgsifOKM7/DQiLqqNEDDhGU= X-MC-Unique: XbPsutRfN1yD8hnyzFsqkg-1 From: David Hildenbrand To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, David Hildenbrand , Paolo Bonzini , Peter Xu , Igor Mammedov , Thiner Logoer , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , Stefan Hajnoczi , Elena Ufimtseva , Jagannathan Raman , "Michael S. Tsirkin" , Ani Sinha , Xiao Guangrong , Daniel Henrique Barboza , Greg Kurz , Eric Blake , Markus Armbruster , Eduardo Habkost Subject: [PATCH v3 03/11] backends/hostmem-file: Add "rom" property to support VM templating with R/O files Date: Wed, 23 Aug 2023 17:34:03 +0200 Message-ID: <20230823153412.832081-4-david@redhat.com> In-Reply-To: <20230823153412.832081-1-david@redhat.com> References: <20230823153412.832081-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=david@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1692804990862100001 Content-Type: text/plain; charset="utf-8" For now, "share=3Doff,readonly=3Don" would always result in us opening the file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively turning it into ROM. Especially for VM templating, "share=3Doff" is a common use case. However, that use case is impossible with files that lack write permissions, because "share=3Doff,readonly=3Don" will not give us writable RAM. The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we have users (Kata Containers) that rely on the existing behavior -- malicious VMs should not be able to consume COW memory for R/O NVDIMMs -- we cannot change the semantics of "share=3Doff,readonly=3Don" So let's add a new "rom" property with on/off/auto values. "auto" is the default and what most people will use: for historical reasons, to not change the old semantics, it defaults to the value of the "readonly" property. For VM templating, one can now use: -object memory-backend-file,share=3Doff,readonly=3Don,rom=3Doff,... But we'll disallow: -object memory-backend-file,share=3Don,readonly=3Don,rom=3Doff,... because we would otherwise get an error when trying to mmap the R/O file shared and writable. An explicit error message is cleaner. We will also disallow for now: -object memory-backend-file,share=3Doff,readonly=3Doff,rom=3Don,... -object memory-backend-file,share=3Don,readonly=3Doff,rom=3Don,... It's not harmful, but also not really required for now. Alternatives that were abandoned: * Make "unarmed=3Don" for the NVDIMM set the memory region container readonly. We would still see a change of ROM->RAM and possibly run into memslot limits with vhost-user. Further, there might be use cases for "unarmed=3Don" that should still allow writing to that memory (temporary files, system RAM, ...). * Add a new "readonly=3Don/off/auto" parameter for NVDIMMs. Similar issues as with "unarmed=3Don". * Make "readonly" consume "on/off/file" instead of being a 'bool' type. This would slightly changes the behavior of the "readonly" parameter: values like true/false (as accepted by a 'bool'type) would no longer be accepted. Signed-off-by: David Hildenbrand Acked-by: Markus Armbruster --- backends/hostmem-file.c | 59 ++++++++++++++++++++++++++++++++++++++++- qapi/qom.json | 17 +++++++++++- qemu-options.hx | 16 ++++++++++- 3 files changed, 89 insertions(+), 3 deletions(-) diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c index ef2d5533af..361d4a8103 100644 --- a/backends/hostmem-file.c +++ b/backends/hostmem-file.c @@ -18,6 +18,8 @@ #include "sysemu/hostmem.h" #include "qom/object_interfaces.h" #include "qom/object.h" +#include "qapi/visitor.h" +#include "qapi/qapi-visit-common.h" =20 OBJECT_DECLARE_SIMPLE_TYPE(HostMemoryBackendFile, MEMORY_BACKEND_FILE) =20 @@ -31,6 +33,7 @@ struct HostMemoryBackendFile { bool discard_data; bool is_pmem; bool readonly; + OnOffAuto rom; }; =20 static void @@ -53,9 +56,33 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Er= ror **errp) return; } =20 + switch (fb->rom) { + case ON_OFF_AUTO_AUTO: + /* Traditionally, opening the file readonly always resulted in ROM= . */ + fb->rom =3D fb->readonly ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF; + break; + case ON_OFF_AUTO_ON: + if (!fb->readonly) { + error_setg(errp, "property 'rom' =3D 'on' is not supported wit= h" + " 'readonly' =3D 'off'"); + return; + } + break; + case ON_OFF_AUTO_OFF: + if (fb->readonly && backend->share) { + error_setg(errp, "property 'rom' =3D 'off' is incompatible wit= h" + " 'readonly' =3D 'on' and 'share' =3D 'on'"); + return; + } + break; + default: + assert(false); + } + name =3D host_memory_backend_get_name(backend); ram_flags =3D backend->share ? RAM_SHARED : 0; - ram_flags |=3D fb->readonly ? RAM_READONLY | RAM_READONLY_FD : 0; + ram_flags |=3D fb->readonly ? RAM_READONLY_FD : 0; + ram_flags |=3D fb->rom =3D=3D ON_OFF_AUTO_ON ? RAM_READONLY : 0; ram_flags |=3D backend->reserve ? 0 : RAM_NORESERVE; ram_flags |=3D fb->is_pmem ? RAM_PMEM : 0; ram_flags |=3D RAM_NAMED_FILE; @@ -201,6 +228,32 @@ static void file_memory_backend_set_readonly(Object *o= bj, bool value, fb->readonly =3D value; } =20 +static void file_memory_backend_get_rom(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + HostMemoryBackendFile *fb =3D MEMORY_BACKEND_FILE(obj); + OnOffAuto rom =3D fb->rom; + + visit_type_OnOffAuto(v, name, &rom, errp); +} + +static void file_memory_backend_set_rom(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + HostMemoryBackend *backend =3D MEMORY_BACKEND(obj); + HostMemoryBackendFile *fb =3D MEMORY_BACKEND_FILE(obj); + + if (host_memory_backend_mr_inited(backend)) { + error_setg(errp, "cannot change property '%s' of %s.", name, + object_get_typename(obj)); + return; + } + + visit_type_OnOffAuto(v, name, &fb->rom, errp); +} + static void file_backend_unparent(Object *obj) { HostMemoryBackend *backend =3D MEMORY_BACKEND(obj); @@ -243,6 +296,10 @@ file_backend_class_init(ObjectClass *oc, void *data) object_class_property_add_bool(oc, "readonly", file_memory_backend_get_readonly, file_memory_backend_set_readonly); + object_class_property_add(oc, "rom", "OnOffAuto", + file_memory_backend_get_rom, file_memory_backend_set_rom, NULL, NU= LL); + object_class_property_set_description(oc, "rom", + "Whether to create Read Only Memory (ROM)"); } =20 static void file_backend_instance_finalize(Object *o) diff --git a/qapi/qom.json b/qapi/qom.json index fa3e88c8e6..c53ef978ff 100644 --- a/qapi/qom.json +++ b/qapi/qom.json @@ -668,6 +668,20 @@ # @readonly: if true, the backing file is opened read-only; if false, # it is opened read-write. (default: false) # +# @rom: whether to create Read Only Memory (ROM) that cannot be modified +# by the VM. Any write attempts to such ROM will be denied. Most +# use cases want writable RAM instead of ROM. However, selected use +# cases, like R/O NVDIMMs, can benefit from ROM. If set to 'on', +# create ROM; if set to 'off', create writable RAM; if set to +# 'auto', the value of the @readonly property is used. This +# property is primarily helpful when we want to have proper RAM in +# configurations that would traditionally create ROM before this +# property was introduced: VM templating, where we want to open a +# file readonly (@readonly set to true) and mark the memory to be +# private for QEMU (@share set to false). For this use case, we need +# writable RAM instead of ROM, and want to set this property to 'off= '. +# (default: auto, since 8.2) +# # Since: 2.1 ## { 'struct': 'MemoryBackendFileProperties', @@ -677,7 +691,8 @@ '*discard-data': 'bool', 'mem-path': 'str', '*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' }, - '*readonly': 'bool' } } + '*readonly': 'bool', + '*rom': 'OnOffAuto' } } =20 ## # @MemoryBackendMemfdProperties: diff --git a/qemu-options.hx b/qemu-options.hx index 29b98c3d4c..44035a0490 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4976,7 +4976,7 @@ SRST they are specified. Note that the 'id' property must be set. These objects are placed in the '/objects' path. =20 - ``-object memory-backend-file,id=3Did,size=3Dsize,mem-path=3Ddir,share= =3Don|off,discard-data=3Don|off,merge=3Don|off,dump=3Don|off,prealloc=3Don|= off,host-nodes=3Dhost-nodes,policy=3Ddefault|preferred|bind|interleave,alig= n=3Dalign,offset=3Doffset,readonly=3Don|off`` + ``-object memory-backend-file,id=3Did,size=3Dsize,mem-path=3Ddir,share= =3Don|off,discard-data=3Don|off,merge=3Don|off,dump=3Don|off,prealloc=3Don|= off,host-nodes=3Dhost-nodes,policy=3Ddefault|preferred|bind|interleave,alig= n=3Dalign,offset=3Doffset,readonly=3Don|off,rom=3Don|off|auto`` Creates a memory file backend object, which can be used to back the guest RAM with huge pages. =20 @@ -5066,6 +5066,20 @@ SRST The ``readonly`` option specifies whether the backing file is open= ed read-only or read-write (default). =20 + The ``rom`` option specifies whether to create Read Only Memory + (ROM) that cannot be modified by the VM. Any write attempts to such + ROM will be denied. Most use cases want proper RAM instead of ROM. + However, selected use cases, like R/O NVDIMMs, can benefit from + ROM. If set to ``on``, create ROM; if set to ``off``, create + writable RAM; if set to ``auto`` (default), the value of the + ``readonly`` option is used. This option is primarily helpful when + we want to have writable RAM in configurations that would + traditionally create ROM before the ``rom`` option was introduced: + VM templating, where we want to open a file readonly + (``readonly=3Don``) and mark the memory to be private for QEMU + (``share=3Doff``). For this use case, we need writable RAM instead + of ROM, and want to also set ``rom=3Doff``. + ``-object memory-backend-ram,id=3Did,merge=3Don|off,dump=3Don|off,shar= e=3Don|off,prealloc=3Don|off,size=3Dsize,host-nodes=3Dhost-nodes,policy=3Dd= efault|preferred|bind|interleave`` Creates a memory backend object, which can be used to back the guest RAM. Memory backend objects offer more control than the --=20 2.41.0