From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, "David Hildenbrand" <david@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Thiner Logoer" <logoerthiner1@163.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
"Jagannathan Raman" <jag.raman@oracle.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Ani Sinha" <anisinha@redhat.com>,
"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
"Greg Kurz" <groug@kaod.org>, "Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>
Subject: [PATCH v2 3/9] backends/hostmem-file: Add "rom" property to support VM templating with R/O files
Date: Tue, 22 Aug 2023 13:44:51 +0200 [thread overview]
Message-ID: <20230822114504.239505-4-david@redhat.com> (raw)
In-Reply-To: <20230822114504.239505-1-david@redhat.com>
For now, "share=off,readonly=on" 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=off" is a common use case. However,
that use case is impossible with files that lack write permissions,
because "share=off,readonly=on" 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=off,readonly=on"
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=off,readonly=on,rom=off,...
But we'll disallow:
-object memory-backend-file,share=on,readonly=on,rom=off,...
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=off,readonly=off,rom=on,...
-object memory-backend-file,share=on,readonly=off,rom=on,...
It's not harmful, but also not really required for now.
Alternatives that were abandoned:
* Make "unarmed=on" 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=on" that should still allow writing to that memory
(temporary files, system RAM, ...).
* Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues
as with "unarmed=on".
* 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 <david@redhat.com>
---
backends/hostmem-file.c | 59 ++++++++++++++++++++++++++++++++++++++++-
qapi/qom.json | 6 ++++-
qemu-options.hx | 10 ++++++-
3 files changed, 72 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"
OBJECT_DECLARE_SIMPLE_TYPE(HostMemoryBackendFile, MEMORY_BACKEND_FILE)
@@ -31,6 +33,7 @@ struct HostMemoryBackendFile {
bool discard_data;
bool is_pmem;
bool readonly;
+ OnOffAuto rom;
};
static void
@@ -53,9 +56,33 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
return;
}
+ switch (fb->rom) {
+ case ON_OFF_AUTO_AUTO:
+ /* Traditionally, opening the file readonly always resulted in ROM. */
+ fb->rom = fb->readonly ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
+ break;
+ case ON_OFF_AUTO_ON:
+ if (!fb->readonly) {
+ error_setg(errp, "property 'rom' = 'on' is not supported with"
+ " 'readonly' = 'off'");
+ return;
+ }
+ break;
+ case ON_OFF_AUTO_OFF:
+ if (fb->readonly && backend->share) {
+ error_setg(errp, "property 'rom' = 'off' is incompatible with"
+ " 'readonly' = 'on' and 'share' = 'on'");
+ return;
+ }
+ break;
+ default:
+ assert(false);
+ }
+
name = host_memory_backend_get_name(backend);
ram_flags = backend->share ? RAM_SHARED : 0;
- ram_flags |= fb->readonly ? RAM_READONLY | RAM_READONLY_FD : 0;
+ ram_flags |= fb->readonly ? RAM_READONLY_FD : 0;
+ ram_flags |= fb->rom == ON_OFF_AUTO_ON ? RAM_READONLY : 0;
ram_flags |= backend->reserve ? 0 : RAM_NORESERVE;
ram_flags |= fb->is_pmem ? RAM_PMEM : 0;
ram_flags |= RAM_NAMED_FILE;
@@ -201,6 +228,32 @@ static void file_memory_backend_set_readonly(Object *obj, bool value,
fb->readonly = value;
}
+static void file_memory_backend_get_rom(Object *obj, Visitor *v,
+ const char *name, void *opaque,
+ Error **errp)
+{
+ HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
+ OnOffAuto rom = 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 = MEMORY_BACKEND(obj);
+ HostMemoryBackendFile *fb = 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 = 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, NULL);
+ object_class_property_set_description(oc, "rom",
+ "Whether to create Read Only Memory (ROM)");
}
static void file_backend_instance_finalize(Object *o)
diff --git a/qapi/qom.json b/qapi/qom.json
index fa3e88c8e6..0cf83c6f39 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -668,6 +668,9 @@
# @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). If set to 'auto', it
+# defaults to the value of @readonly. (default: auto, since 8.2)
+#
# Since: 2.1
##
{ 'struct': 'MemoryBackendFileProperties',
@@ -677,7 +680,8 @@
'*discard-data': 'bool',
'mem-path': 'str',
'*pmem': { 'type': 'bool', 'if': 'CONFIG_LIBPMEM' },
- '*readonly': 'bool' } }
+ '*readonly': 'bool',
+ '*rom': 'OnOffAuto' } }
##
# @MemoryBackendMemfdProperties:
diff --git a/qemu-options.hx b/qemu-options.hx
index 29b98c3d4c..03ce0b0a30 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.
- ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off``
+ ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align,offset=offset,readonly=on|off,rom=on|off|auto``
Creates a memory file backend object, which can be used to back
the guest RAM with huge pages.
@@ -5066,6 +5066,14 @@ SRST
The ``readonly`` option specifies whether the backing file is opened
read-only or read-write (default).
+ The ``rom`` option specifies whether to create Read Only Memory (ROM)
+ that cannot be modified by the VM. If set to ``on``, the VM cannot
+ modify the memory. If set to ``off``, the VM can modify the memory.
+ If set to ``auto`` (default), the value of the ``readonly`` property
+ is used. This option is primarily helpful for VM templating, where we
+ want to open a file readonly (``readonly=on``) and allow private
+ modifications of the memory by the VM (``share=off``, ``rom=off``).
+
``-object memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|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
--
2.41.0
next prev parent reply other threads:[~2023-08-22 11:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 11:44 [PATCH v2 0/9] memory-backend-file related improvements and VM templating support David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 1/9] nvdimm: Reject writing label data to ROM instead of crashing QEMU David Hildenbrand
2023-08-22 19:25 ` Stefan Hajnoczi
2023-08-22 11:44 ` [PATCH v2 2/9] softmmu/physmem: Distinguish between file access mode and mmap protection David Hildenbrand
2023-08-22 13:13 ` ThinerLogoer
2023-08-22 13:25 ` [PATCH " David Hildenbrand
2023-08-22 11:44 ` David Hildenbrand [this message]
2023-08-22 13:27 ` [PATCH v2 3/9] backends/hostmem-file: Add "rom" property to support VM templating with R/O files Markus Armbruster
2023-08-22 13:29 ` David Hildenbrand
2023-08-22 14:26 ` ThinerLogoer
2023-08-23 12:43 ` [PATCH " David Hildenbrand
2023-08-23 14:47 ` ThinerLogoer
2023-08-23 14:59 ` David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 4/9] softmmu/physmem: Remap with proper protection in qemu_ram_remap() David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 5/9] softmmu/physmem: Bail out early in ram_block_discard_range() with readonly files David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 6/9] softmmu/physmem: Fail creation of new files in file_ram_open() with readonly=true David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 7/9] softmmu/physmem: Never return directories from file_ram_open() David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 8/9] docs: Don't mention "-mem-path" in multi-process.rst David Hildenbrand
2023-08-22 13:21 ` ThinerLogoer
2023-08-22 13:24 ` [PATCH " David Hildenbrand
2023-08-22 11:44 ` [PATCH v2 9/9] docs: Start documenting VM templating David Hildenbrand
2023-08-22 13:47 ` Daniel P. Berrangé
2023-08-22 14:04 ` David Hildenbrand
2023-08-22 14:23 ` Peter Maydell
2023-08-22 14:31 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230822114504.239505-4-david@redhat.com \
--to=david@redhat.com \
--cc=anisinha@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=danielhb413@gmail.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=elena.ufimtseva@oracle.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=jag.raman@oracle.com \
--cc=logoerthiner1@163.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.