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

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

[marcandre.lureau]

From: Marc-André Lureau <marcandre.lureau@redhat.com>

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 <marcandre.lureau@redhat.com>
---
 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
+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.
+
 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.
+
 The device MUST NOT modify memory or memory properties of plugged memory
 blocks.
 
-- 
2.53.0

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

[Matias Ezequiel Vara Larsen]

Hello Marc, 

I did a first review of the patch:

On Wed, Apr 15, 2026 at 06:54:35PM +0400, marcandre.lureau@redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> 
> 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 <marcandre.lureau@redhat.com>
> ---
>  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
> 
> 

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

[Marc-André Lureau]

Hi

On Mon, Apr 20, 2026 at 5:52 PM Matias Ezequiel Vara Larsen
<mvaralar@redhat.com> wrote:
>
> Hello Marc,
>
> I did a first review of the patch:
>
> On Wed, Apr 15, 2026 at 06:54:35PM +0400, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > 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 <marcandre.lureau@redhat.com>
> > ---
> >  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.

This is up to the platform at this point (both on host and guest
side). Given that the setup are different for the different platforms,
I think this should remain outside the scope of virtio spec.

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

True, it's mostly redundant.

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

Since it is marked inaccessible, the guest can legitimately not to
convert it to share. But since we want to return it in the initial
share state, the device has to convert it back to share itself. If it
can't, then it's a hard failure - or it should just discard that
memory.

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

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

[Marc-André Lureau]

Hi

On Wed, May 13, 2026 at 8:07 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/15/26 16:54, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > 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 <marcandre.lureau@redhat.com>
> > ---
> >  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
> > +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.
>
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is a legacy leftover.
>
> Should we rather enforce that such devices in CoCo environments MUST advertise
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE? So they would always have to be converted back.

If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is negotiated, the guest
doesn't have to convert it back.

I am not sure enforcing VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE for CoCo
is the right call.

> Note that negotiation with VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE does not really
> apply: if the device has VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, but the guest
> driver does not support it, the expectation is that feature validation fails
> (see QEMU).
>
>
> > +
> >  \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.
>
> That makes sense. But doesn't that fall under "memory properties" above?

Yes, it's a bit redundant, we can drop it.

>
> > +
> >  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.
>
> Again, I think we should turn that into a MUST.
>
> > +
> >  \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.
> > +
>
> Is it guaranteed on all platforms (TDX/SEV-SNP/CCA/...) that hotplugged memory
> will appear in the shared state? I have some faint recollection that some
> platforms would start out with new memory in the private state (that they would
> still have to accept before use. But cocneptually, the memory is in the private
> state).

My knowledge is limited. I think the platform doesn't enforce this; it
depends on the implementation. To fix plug/replug I propose to enforce
the state from either fully shared or private:
https://patchew.org/QEMU/20260504-rdm5-v4-0-bdf61e57c1e1@redhat.com/20260504-rdm5-v4-13-bdf61e57c1e1@redhat.com/

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

[Marc-André Lureau]

Hi

On Wed, May 20, 2026 at 7:23 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 5/18/26 13:39, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, May 13, 2026 at 8:07 PM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 4/15/26 16:54, marcandre.lureau@redhat.com wrote:
> >>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>>
> >>> 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 <marcandre.lureau@redhat.com>
> >>> ---
> >>>  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
> >>> +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.
> >>
> >> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is a legacy leftover.
> >>
> >> Should we rather enforce that such devices in CoCo environments MUST advertise
> >> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE? So they would always have to be converted back.
> >
> > If VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is negotiated, the guest
> > doesn't have to convert it back.
> >
> > I am not sure enforcing VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE for CoCo
> > is the right call.
>
> Can you elaborate why? What's the use case and would it actually work, for
> example, in QEMU with a CoCo VM?

Sorry, I misunderstood the purpose of the flag. It prevents the guest
from accessing unplugged memory (I thought it was meant for the host).

So let's make this a MUST

>
> [...]
>
> >>
> >> Is it guaranteed on all platforms (TDX/SEV-SNP/CCA/...) that hotplugged memory
> >> will appear in the shared state? I have some faint recollection that some
> >> platforms would start out with new memory in the private state (that they would
> >> still have to accept before use. But cocneptually, the memory is in the private
> >> state).
> >
> > My knowledge is limited. I think the platform doesn't enforce this; it
> > depends on the implementation. To fix plug/replug I propose to enforce
> > the state from either fully shared or private:
> > https://patchew.org/QEMU/20260504-rdm5-v4-0-bdf61e57c1e1@redhat.com/20260504-rdm5-v4-13-bdf61e57c1e1@redhat.com/
>
> Okay, that only touches TDX. We really have to be careful here to not document
> something that is specific to one platform.
>
> I can try asking some folks in the bi-weekly guest-memfd call in June.

ok, thanks!