Re: [PATCH RFC] virtio-mem: add shared/private memory property details

Matias Ezequiel Vara Larsen <[email protected]> Mon, 20 Apr 2026 15:52:40 +0200
Newsgroups dev.linux.lists.virtio-comment
Message-ID <aeYvqOTMziofz2yF@fedora>
Hello Marc, 

I did a first review of the patch:

On Wed, Apr 15, 2026 at 06:54:35PM +0400, [email protected] wrote:
> From: Marc-AndrĂ© Lureau <[email protected]>
> 
> Add specification text for platforms where system RAM has a
> shared/private property (e.g., confidential computing environments such
> as AMD SEV-SNP or Intel TDX). Define the device and driver requirements
> for memory state transitions during plug/unplug operations, and
> guidance for VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE case.
> 
> Signed-off-by: Marc-AndrĂ© Lureau <[email protected]>
> ---
>  device-types/mem/description.tex | 37 ++++++++++++++++++++++++++++++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/device-types/mem/description.tex b/device-types/mem/description.tex
> index 9acf63f..1eefea0 100644
> --- a/device-types/mem/description.tex
> +++ b/device-types/mem/description.tex
> @@ -42,6 +42,18 @@ \section{Memory Device}\label{sec:Device Types / Memory Device}
>  provides the exact same properties with the exact same semantics for
>  plugged device memory as available for comparable RAM in the same configuration.
>  
> +In some configurations, system RAM might additionally have a shared/private
> +property, indicating whether memory is accessible to both the guest and the
> +host (shared) or only to the guest (private). \footnote{For example, in

How does the driver know if the platform has this memory property?,
i.e., shared/private property. 

> +confidential computing environments such as AMD SEV-SNP or Intel TDX.
> +The mechanism for converting between shared and private states is
> +platform-specific; for example, it might involve dedicated CPU instructions
> +or hypercalls.} The device provides unplugged memory in the shared state.
> +When memory blocks are plugged, the driver is expected to convert them to
> +the private state before use. Unless VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
> +has been negotiated, the driver is expected to convert them back to the
> +shared state before unplugging.
> +
>  \subsection{Device ID}\label{sec:Device Types / Memory Device / Device ID}
>  24
>  
> @@ -58,8 +70,9 @@ \subsection{Feature bits}\label{sec:Device Types / Memory Device / Feature bits}
>  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. \footnote{On platforms with memory properties that
> -might get modified implicitly on memory access, this feature is expected to
> -be offered by the device.}
> +might get modified implicitly on memory access, or on platforms with a
> +shared/private memory property, this feature is expected to be offered by
> +the device.}
>  \item[VIRTIO_MEM_F_PERSISTENT_SUSPEND (2)] The driver can allow the guest
>  to enter suspended state (deep sleep, suspend-to-RAM).
>  \end{description}
> @@ -176,9 +189,15 @@ \subsection{Device Initialization}\label{Device Types / Memory Device / Device I
>  The device MUST NOT modify memory or memory properties of plugged memory
>  blocks during device reset.
>  
> +On platforms with a shared/private memory property, the device MUST NOT
> +change the shared/private state of memory blocks during device reset.
> +

Is this additional requirement needed? Is not already covered by the
previous one about `plugged memory blocks`? Is shared/private a memory
property?

>  The device SHOULD offer VIRTIO_MEM_F_PERSISTENT_SUSPEND if the platform
>  supports suspending (deep sleep, suspend-to-RAM) with plugged memory blocks.
>  
> +The device SHOULD offer VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE if the platform
> +has a shared/private memory property.
> +
>  \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Operation}
>  
>  The device notifies the driver about the amount of memory the device wants
> @@ -256,6 +275,15 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
>  If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated, the driver
>  MUST NOT read memory or query memory properties of unplugged memory blocks.
>  
> +On platforms with a shared/private memory property, the driver MUST convert
> +plugged memory blocks to the private state before initializing or otherwise
> +using them.
> +
> +On platforms with a shared/private memory property, the driver MUST convert
> +memory blocks to the shared state before requesting to unplug them (for
> +VIRTIO_MEM_REQ_UNPLUG_ALL, this applies to all plugged memory blocks), unless
> +VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated.
> +
>  The driver MUST NOT request unplug of memory blocks while corresponding memory
>  or memory properties are still in use.
>  
> @@ -285,6 +313,11 @@ \subsection{Device Operation}\label{sec:Device Types / Memory Device / Device Op
>  The device MAY modify memory of unplugged memory blocks or reset memory
>  properties of such memory blocks to platform defaults at any time.
>  
> +On platforms with a shared/private memory property, the device MUST provide
> +unplugged memory blocks in the shared state.  If
> +VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated, the device MUST
> +convert memory blocks to the shared state after unplugging them.

I wonder if the device can always do such a conversion, i.e., from
private to shared, or it should go through the guest.

> +
>  The device MUST NOT modify memory or memory properties of plugged memory
>  blocks.
>  
> -- 
> 2.53.0
> 
>