qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 03/11] backends/hostmem-file: Add "rom" property to suppor


From: Markus Armbruster
Subject: Re: [PATCH v3 03/11] backends/hostmem-file: Add "rom" property to support VM templating with R/O files
Date: Fri, 01 Sep 2023 14:50:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

David Hildenbrand <david@redhat.com> writes:

> 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>

QAPI schema
Acked-by: Markus Armbruster <armbru@redhat.com>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]