[PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[David Hildenbrand]

Looking into supporting virtio-mem
a) without a shared zeropage for the memory backing of the device --
   not allowing the driver to read unplugged memory
b) on architectures with memory properties for RAM (e.g., s390x with
   storage keys and storage attributes)
requires extension of the spec to handle both cases cleanly and describe
the expected semantics.

I'll open a github issue soon; in the meantime, I'll work on the actual
implementation in QEMU and Linux.

For a), I already shared a Linux implementation in the past [1], which will
be simplified once virito-mem memory can no longer be mapped via /dev/mem
[2].

For b), it's actually unlocking virtio-mem on s390x in QEMU/Linux,
initially supporting storage keys but not supporting storage attributes
for simplicity.

[1] https://lkml.kernel.org/r/20210215122421.27964-1-david@redhat.com
[2] https://lkml.kernel.org/r/20210902160919.25683-1-david@redhat.com

Cc: Hui Zhu <teawater@gmail.com>
Cc: Marek Kedzierski <mkedzier@redhat.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Halil Pasic <pasic@linux.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>

v1-> v2:
- Addressed all feedback from Conny.
- Added patch #1-#3 to cleanup and clarify.

David Hildenbrand (5):
  virtio-mem: simplify statements that express unexpected behavior on
    memory access
  virtio-mem: rephrase remaining memory access statements
  virtio-mem: document basic memory access to plugged memory blocks
  virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
  virtio-mem: describe interaction with memory properties

 virtio-mem.tex | 72 +++++++++++++++++++++++++++++++++++---------------
 1 file changed, 51 insertions(+), 21 deletions(-)

-- 
2.31.1

[PATCH RESEND v2 1/5] virtio-mem: simplify statements that express unexpected behavior on memory access

[David Hildenbrand]

Some statements express that the device MAY allow access to memory inside
unplugged memory blocks, although it's really just unexpected behavior and
conforming drivers MUST NOT perform such access.

Clarify that, and move the special CPU vs. DMA handling for some
unplugged memory blocks to the driver section instead.

While at it, start rephrasing our statements to clarify and prepare for
further changes.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 virtio-mem.tex | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index 62a1d02..f0c5970 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -220,8 +220,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}.
+The driver MUST NOT read memory of unplugged memory blocks inside
+\field{usable_region_size} via DMA.
+
+The driver SHOULD NOT read memory of unplugged memory blocks inside
+\field{usable_region_size} via the CPU.
 
 The driver MUST NOT request to unplug memory blocks while the memory is
 still in use.
@@ -246,18 +249,10 @@ \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.}
-
-The device MAY allow to read from unplugged memory blocks inside the
-usable device-managed region via DMA.
-
-The device MAY allow to read from unplugged memory blocks outside
-the usable device-managed region.
-
-The device MAY allow to write to unplugged memory blocks.
+The device MUST allow the driver to read memory of unplugged memory blocks
+inside \field{usable_region_size} via the CPU. \footnote{To allow for simplified
+dumping of memory. The CPU is expected to copy such memory to another location
+before starting DMA.}
 
 The device MAY change the state of memory blocks during system resets.
 
-- 
2.31.1

[PATCH RESEND v2 2/5] virtio-mem: rephrase remaining memory access statements

[David Hildenbrand]

Let's rephrase the remaining statements regarding memory access to unify
and prepare for further changes.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 virtio-mem.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index f0c5970..cca3c9f 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -215,9 +215,9 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 
 \drivernormative{\subsubsection}{Device Operation}{Device Types / Memory Device / Device Operation}
 
-The driver MUST NOT write to unplugged memory blocks.
+The driver MUST NOT write memory of unplugged memory blocks.
 
-The driver MUST NOT read from unplugged memory blocks outside
+The driver MUST NOT read memory of unplugged memory blocks outside
 \field{usable_region_size}.
 
 The driver MUST NOT read memory of unplugged memory blocks inside
-- 
2.31.1

[virtio-comment] [PATCH RESEND v2 3/5] virtio-mem: document basic memory access to plugged memory blocks

[David Hildenbrand]

Let's cleanly document that the driver just has to allow for access to
plugged memory blocks.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 virtio-mem.tex | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index cca3c9f..3860b8c 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -249,6 +249,9 @@ \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 driver to read and write memory of plugged
+memory blocks.
+
 The device MUST allow the driver to read memory of unplugged memory blocks
 inside \field{usable_region_size} via the CPU. \footnote{To allow for simplified
 dumping of memory. The CPU is expected to copy such memory to another location
-- 
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/

[PATCH RESEND v2 4/5] virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE

[David Hildenbrand]

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 | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index 3860b8c..dce035c 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 is not allowed to
+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
@@ -223,9 +231,13 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 The driver MUST NOT read memory of unplugged memory blocks inside
 \field{usable_region_size} via DMA.
 
-The driver SHOULD NOT read memory of unplugged memory blocks inside
+If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has not been negotiated, the driver
+SHOULD NOT read memory of unplugged memory blocks inside
 \field{usable_region_size} via the CPU.
 
+If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated, 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.
 
@@ -252,10 +264,11 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 The device MUST allow the driver to read and write memory of plugged
 memory blocks.
 
-The device MUST allow the driver to read memory of unplugged memory blocks
-inside \field{usable_region_size} via the CPU. \footnote{To allow for simplified
-dumping of memory. The CPU is expected to copy such memory to another location
-before starting DMA.}
+If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has not been negotiated, the device
+MUST allow the driver to read memory of unplugged memory blocks inside
+\field{usable_region_size} via the CPU. \footnote{To allow for simplified
+dumping of memory. The CPU is expected to copy such memory to another
+location before starting DMA.}
 
 The device MAY change the state of memory blocks during system resets.
 
-- 
2.31.1

[PATCH RESEND v2 5/5] virtio-mem: describe interaction with memory properties

[David Hildenbrand]

Let's describe how we expect the interaction with memory properties that
might be available on a specific platform for ordinary system RAM.

This is primarily a preparation for s390x support, which provides
storage keys and may provide storage attributes, depending on the system
configuration.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 virtio-mem.tex | 61 +++++++++++++++++++++++++++++++++-----------------
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/virtio-mem.tex b/virtio-mem.tex
index dce035c..0a6d558 100644
--- a/virtio-mem.tex
+++ b/virtio-mem.tex
@@ -32,6 +32,16 @@ \section{Memory Device}\label{sec:Device Types / Memory Device}
 expose plugged memory blocks to the operating system as system RAM,
 available for the page allocator.
 
+Some platforms provide memory properties for system RAM that are usually
+queried and modified using special CPU instructions. Memory properties might
+be implicitly queried or modified on memory access. Memory properties can
+include advanced memory protection, access and change indication, or memory
+usage indication relevant in virtualized environments. \footnote{For example,
+s390x provides storage keys for each 4 KiB page and may, depending on the
+configuration, provide storage attributes for each 4 KiB page.} The device
+provides the exact same properties with the exact same semantics for
+plugged device memory as available for comparable RAM in the same configuration.
+
 \subsection{Device ID}\label{sec:Device Types / Memory Device / Device ID}
 24
 
@@ -47,7 +57,9 @@ \subsection{Feature bits}\label{sec:Device Types / Memory Device / Feature bits}
 \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 is not allowed to
-access unplugged memory.
+access unplugged memory. \footnote{On platforms with memory properties that
+might get modified implicitly on memory access, this feature is expected to
+be offered by the device.}
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / Memory Device / Device configuration layout}
@@ -159,8 +171,8 @@ \subsection{Device Initialization}\label{Device Types / Memory Device / Device I
 
 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
-device reset.
+The device MUST NOT modify memory or memory properties of plugged memory
+blocks during device reset.
 
 \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Operation}
 
@@ -223,23 +235,24 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 
 \drivernormative{\subsubsection}{Device Operation}{Device Types / Memory Device / Device Operation}
 
-The driver MUST NOT write memory of unplugged memory blocks.
+The driver MUST NOT write memory or modify memory properties of
+unplugged memory blocks.
 
-The driver MUST NOT read memory of unplugged memory blocks outside
-\field{usable_region_size}.
+The driver MUST NOT read memory or query memory properties of unplugged memory
+blocks outside \field{usable_region_size}.
 
-The driver MUST NOT read memory of unplugged memory blocks inside
-\field{usable_region_size} via DMA.
+The driver MUST NOT read memory or query memory properties of unplugged memory
+blocks inside \field{usable_region_size} via DMA.
 
 If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has not been negotiated, the driver
-SHOULD NOT read memory of unplugged memory blocks inside
-\field{usable_region_size} via the CPU.
+SHOULD NOT read memory or query memory properties of unplugged memory blocks
+inside \field{usable_region_size} via the CPU.
 
 If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated, the driver
-MUST NOT read memory of unplugged memory blocks.
+MUST NOT read memory or query memory properties of unplugged memory blocks.
 
-The driver MUST NOT request to unplug memory blocks while the memory is
-still in use.
+The driver MUST NOT request unplug of memory blocks while corresponding memory
+or memory properties are still in use.
 
 The driver SHOULD initialize memory blocks after plugging them, the content
 is undefined.
@@ -257,18 +270,24 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
 
 \devicenormative{\subsubsection}{Device Operation}{Device Types / Memory Device / Device Operation}
 
-The device MAY change the content of unplugged memory blocks at any time.
+The device MUST provide the exact same memory properties with the exact same
+semantics for device memory the platform provides in the same configuration for
+comparable RAM.
 
-The device MUST NOT change the content of plugged memory blocks.
+The device MAY modify memory of unplugged memory blocks or reset memory
+properties of such memory blocks to platform defaults at any time.
 
-The device MUST allow the driver to read and write memory of plugged
-memory blocks.
+The device MUST NOT modify memory or memory properties of plugged memory
+blocks.
+
+The device MUST allow the driver to read and write memory and to query
+and modify memory attributes of plugged memory blocks.
 
 If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has not been negotiated, the device
-MUST allow the driver to read memory of unplugged memory blocks inside
-\field{usable_region_size} via the CPU. \footnote{To allow for simplified
-dumping of memory. The CPU is expected to copy such memory to another
-location before starting DMA.}
+MUST allow the driver to read memory and to query memory properties of
+unplugged memory blocks inside \field{usable_region_size} via the CPU.
+\footnote{To allow for simplified dumping of memory. The CPU is expected to
+copy such memory to another location before starting DMA.}
 
 The device MAY change the state of memory blocks during system resets.
 
-- 
2.31.1

[virtio-comment] Re: [PATCH RESEND v2 1/5] virtio-mem: simplify statements that express unexpected behavior on memory access

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Some statements express that the device MAY allow access to memory inside
> unplugged memory blocks, although it's really just unexpected behavior and
> conforming drivers MUST NOT perform such access.
>
> Clarify that, and move the special CPU vs. DMA handling for some
> unplugged memory blocks to the driver section instead.
>
> While at it, start rephrasing our statements to clarify and prepare for
> further changes.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 23 +++++++++--------------
>  1 file changed, 9 insertions(+), 14 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/

[virtio-comment] Re: [PATCH RESEND v2 2/5] virtio-mem: rephrase remaining memory access statements

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Let's rephrase the remaining statements regarding memory access to unify
> and prepare for further changes.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/

Re: [virtio-comment] [PATCH RESEND v2 3/5] virtio-mem: document basic memory access to plugged memory blocks

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Let's cleanly document that the driver just has to allow for access to
> plugged memory blocks.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 3 +++
>  1 file changed, 3 insertions(+)

Not sure whether we actually need this, but it does not hurt.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/

[virtio-comment] Re: [PATCH RESEND v2 4/5] virtio-mem: introduce VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> 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 | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/

[virtio-comment] Re: [PATCH RESEND v2 5/5] virtio-mem: describe interaction with memory properties

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Let's describe how we expect the interaction with memory properties that
> might be available on a specific platform for ordinary system RAM.
>
> This is primarily a preparation for s390x support, which provides
> storage keys and may provide storage attributes, depending on the system
> configuration.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  virtio-mem.tex | 61 +++++++++++++++++++++++++++++++++-----------------
>  1 file changed, 40 insertions(+), 21 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>


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/

[virtio-comment] Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[Cornelia Huck]

On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:

> Looking into supporting virtio-mem
> a) without a shared zeropage for the memory backing of the device --
>    not allowing the driver to read unplugged memory
> b) on architectures with memory properties for RAM (e.g., s390x with
>    storage keys and storage attributes)
> requires extension of the spec to handle both cases cleanly and describe
> the expected semantics.
>
> I'll open a github issue soon; in the meantime, I'll work on the actual
> implementation in QEMU and Linux.

LGTM, but would like a second opinion.

>
> For a), I already shared a Linux implementation in the past [1], which will
> be simplified once virito-mem memory can no longer be mapped via /dev/mem
> [2].
>
> For b), it's actually unlocking virtio-mem on s390x in QEMU/Linux,
> initially supporting storage keys but not supporting storage attributes
> for simplicity.
>
> [1] https://lkml.kernel.org/r/20210215122421.27964-1-david@redhat.com
> [2] https://lkml.kernel.org/r/20210902160919.25683-1-david@redhat.com


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/

Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[David Hildenbrand]

On 23.09.21 17:31, Cornelia Huck wrote:
> On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:
> 
>> Looking into supporting virtio-mem
>> a) without a shared zeropage for the memory backing of the device --
>>     not allowing the driver to read unplugged memory
>> b) on architectures with memory properties for RAM (e.g., s390x with
>>     storage keys and storage attributes)
>> requires extension of the spec to handle both cases cleanly and describe
>> the expected semantics.
>>
>> I'll open a github issue soon; in the meantime, I'll work on the actual
>> implementation in QEMU and Linux.
> 
> LGTM, but would like a second opinion.
Thanks Conny! I'll wait for more feedback before I open a github issue / 
request a vote.

-- 
Thanks,

David / dhildenb

[virtio-comment] Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[Cornelia Huck]

On Fri, Sep 24 2021, David Hildenbrand <david@redhat.com> wrote:

> On 23.09.21 17:31, Cornelia Huck wrote:
>> On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:
>> 
>>> Looking into supporting virtio-mem
>>> a) without a shared zeropage for the memory backing of the device --
>>>     not allowing the driver to read unplugged memory
>>> b) on architectures with memory properties for RAM (e.g., s390x with
>>>     storage keys and storage attributes)
>>> requires extension of the spec to handle both cases cleanly and describe
>>> the expected semantics.
>>>
>>> I'll open a github issue soon; in the meantime, I'll work on the actual
>>> implementation in QEMU and Linux.
>> 
>> LGTM, but would like a second opinion.
> Thanks Conny! I'll wait for more feedback before I open a github issue / 
> request a vote.

Anyone else interested in looking at this?

Otherwise, I'd say just open an issue and request a vote.


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/

Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[David Hildenbrand]

On 06.10.21 12:59, Cornelia Huck wrote:
> On Fri, Sep 24 2021, David Hildenbrand <david@redhat.com> wrote:
> 
>> On 23.09.21 17:31, Cornelia Huck wrote:
>>> On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:
>>>
>>>> Looking into supporting virtio-mem
>>>> a) without a shared zeropage for the memory backing of the device --
>>>>      not allowing the driver to read unplugged memory
>>>> b) on architectures with memory properties for RAM (e.g., s390x with
>>>>      storage keys and storage attributes)
>>>> requires extension of the spec to handle both cases cleanly and describe
>>>> the expected semantics.
>>>>
>>>> I'll open a github issue soon; in the meantime, I'll work on the actual
>>>> implementation in QEMU and Linux.
>>>
>>> LGTM, but would like a second opinion.
>> Thanks Conny! I'll wait for more feedback before I open a github issue /
>> request a vote.
> 
> Anyone else interested in looking at this?
> 
> Otherwise, I'd say just open an issue and request a vote.
> 

Would it make sense to split it into two parts?

VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE: #1-#4
Memory properties: #5

Then I could resend via the split and request two votes.

Thanks!

-- 
Thanks,

David / dhildenb

[virtio-comment] Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[Cornelia Huck]

On Wed, Oct 06 2021, David Hildenbrand <david@redhat.com> wrote:

> On 06.10.21 12:59, Cornelia Huck wrote:
>> On Fri, Sep 24 2021, David Hildenbrand <david@redhat.com> wrote:
>> 
>>> On 23.09.21 17:31, Cornelia Huck wrote:
>>>> On Mon, Sep 20 2021, David Hildenbrand <david@redhat.com> wrote:
>>>>
>>>>> Looking into supporting virtio-mem
>>>>> a) without a shared zeropage for the memory backing of the device --
>>>>>      not allowing the driver to read unplugged memory
>>>>> b) on architectures with memory properties for RAM (e.g., s390x with
>>>>>      storage keys and storage attributes)
>>>>> requires extension of the spec to handle both cases cleanly and describe
>>>>> the expected semantics.
>>>>>
>>>>> I'll open a github issue soon; in the meantime, I'll work on the actual
>>>>> implementation in QEMU and Linux.
>>>>
>>>> LGTM, but would like a second opinion.
>>> Thanks Conny! I'll wait for more feedback before I open a github issue /
>>> request a vote.
>> 
>> Anyone else interested in looking at this?
>> 
>> Otherwise, I'd say just open an issue and request a vote.
>> 
>
> Would it make sense to split it into two parts?
>
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE: #1-#4
> Memory properties: #5
>
> Then I could resend via the split and request two votes.

From my POV, this can go in via one vote[*]. We can also split this up,
if you think that makes sense.

[*] Less votes == less work for me :)


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/

[virtio-comment] Re: [PATCH RESEND v2 0/5] virtio-mem: VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and interaction with memory properties

[David Hildenbrand]

On 20.09.21 15:46, David Hildenbrand wrote:
> Looking into supporting virtio-mem
> a) without a shared zeropage for the memory backing of the device --
>     not allowing the driver to read unplugged memory
> b) on architectures with memory properties for RAM (e.g., s390x with
>     storage keys and storage attributes)
> requires extension of the spec to handle both cases cleanly and describe
> the expected semantics.
> 
> I'll open a github issue soon; in the meantime, I'll work on the actual
> implementation in QEMU and Linux.

Okay, let's request a vote to get this integrated:

Fixes: https://github.com/oasis-tcs/virtio-spec/issues/118

Thanks for the review Conny!

-- 
Thanks,

David / dhildenb


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/