From: David Hildenbrand <david@redhat.com>
To: virtio-comment@lists.oasis-open.org
Cc: David Hildenbrand <david@redhat.com>
Subject: [virtio-comment] [PATCH v1 1/2] virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
Date: Thu, 12 Aug 2021 15:31:49 +0200 [thread overview]
Message-ID: <20210812133150.36146-2-david@redhat.com> (raw)
In-Reply-To: <20210812133150.36146-1-david@redhat.com>
Until now, we allowed a driver to read unplugged memory within the
usable device-managed region: this simplified bring-up of virtio-mem in
Linux quite a bit, especially when it came to physical memory dumping.
When the device is using a memory backend that supports a shared
zeropage, such as virtio-mem in QEMU under Linux on anonymous memory, the
old behavior could be realized easily.
However, when using other memory backends (such as hugetlbfs or shmem)
or architectures, such as s390x, where a shared zeropage either does not
exist or cannot be used, letting the driver read unplugged memory can
result in undesired memory consumption in the hypervisor. The device
wants to make sure that the guest is aware and will not read unplugged
memory, not even in corner cases.
In the meantime, the Linux implementation matured such that it will no
longer access unplugged memory, for example, during kdump, when reading
/proc/kcore, or via (now removed) /dev/kmem.
Similar to VIRTIO_F_ACCESS_PLATFORM, this change will be disruptive and
require driver adaptions -- even if it's just accepting the new feature.
Devices are expected to only set the bit when really required, to keep
existing setups working.
Signed-off-by: David Hildenbrand <david@redhat.com>
---
virtio-mem.tex | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/virtio-mem.tex b/virtio-mem.tex
index 62a1d02..c4dd0d0 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -46,6 +46,8 @@ \subsection{Feature bits}\label{sec:Device Types / Memory Device / Feature bits}
\begin{description}
\item[VIRTIO_MEM_F_ACPI_PXM (0)] The field \field{node_id} in the device
configuration is valid and corresponds to an ACPI PXM.
+\item[VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE (1)] The driver MUST NOT access
+unplugged memory.
\end{description}
\subsection{Device configuration layout}\label{sec:Device Types / Memory Device / Device configuration layout}
@@ -144,11 +146,17 @@ \subsection{Device Initialization}\label{Device Types / Memory Device / Device I
\drivernormative{\subsubsection}{Device Initialization}{Device Types / Memory Device / Device Initialization}
+The driver SHOULD accept VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE if it is
+offered and the driver supports it.
+
The driver SHOULD issue UNPLUG ALL requests until successful if the device
still has memory plugged and the plugged memory is not in use.
\devicenormative{\subsubsection}{Device Initialization}{Device Types / Memory Device / Device Initialization}
+A device MAY fail to operate further if VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
+is not accepted.
+
The device MUST NOT change the state of memory blocks during device reset.
The device MUST NOT change the content of plugged memory blocks during
@@ -220,8 +228,11 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
The driver MUST NOT read from unplugged memory blocks outside
\field{usable_region_size}.
-The driver SHOULD NOT read from unplugged memory blocks inside
-\field{usable_region_size}.
+Without VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, the driver SHOULD NOT read
+memory of unplugged memory blocks inside \field{usable_region_size}.
+
+With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, the driver MUST NOT read memory of
+unplugged memory blocks.
The driver MUST NOT request to unplug memory blocks while the memory is
still in use.
@@ -246,10 +257,13 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
The device MUST NOT change the content of plugged memory blocks.
-The device MUST allow the CPU to read from unplugged memory blocks inside
-the usable device-managed region. \footnote{To allow for simplified dumping of
-memory. The CPU is expected to copy such memory to another location before
-starting DMA.}
+Without VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, the device MUST allow the CPU to
+read memory of unplugged memory blocks inside \field{usable_region_size}.
+\footnote{To allow for simplified dumping of memory. The CPU is expected to
+copy such memory to another location before starting DMA.}
+
+With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, the device MAY allow the CPU to
+read memory of unplugged memory blocks inside \field{usable_region_size}.
The device MAY allow to read from unplugged memory blocks inside the
usable device-managed region via DMA.
--
2.31.1
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2021-08-12 13:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 13:31 [PATCH v1 0/2] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties David Hildenbrand
2021-08-12 13:31 ` David Hildenbrand [this message]
2021-08-17 8:50 ` [virtio-comment] [PATCH v1 1/2] virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE Cornelia Huck
2021-08-17 9:08 ` David Hildenbrand
2021-08-17 9:23 ` Cornelia Huck
2021-08-17 9:27 ` David Hildenbrand
2021-08-17 9:33 ` Cornelia Huck
2021-08-12 13:31 ` [virtio-comment] [PATCH v1 2/2] virtio-mem: describe interaction with memory properties David Hildenbrand
2021-08-17 9:01 ` Cornelia Huck
2021-08-17 9:58 ` David Hildenbrand
2021-08-17 10:24 ` Cornelia Huck
2021-08-17 12:20 ` David Hildenbrand
2021-08-17 13:25 ` Cornelia Huck
2021-08-17 13:27 ` 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=20210812133150.36146-2-david@redhat.com \
--to=david@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
/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.