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

Hi

On Wed, May 13, 2026 at 8:07=E2=80=AFPM David Hildenbrand (Arm)
<[email protected]> wrote:
>
> On 4/15/26 16:54, [email protected] wrote:
> > From: Marc-Andr=C3=A9 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=C3=A9 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/descri=
ption.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 / Mem=
ory Device}
> >  provides the exact same properties with the exact same semantics for
> >  plugged device memory as available for comparable RAM in the same conf=
iguration.
> >
> > +In some configurations, system RAM might additionally have a shared/pr=
ivate
> > +property, indicating whether memory is accessible to both the guest an=
d the
> > +host (shared) or only to the guest (private). \footnote{For example, i=
n
> > +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 instruc=
tions
> > +or hypercalls.} The device provides unplugged memory in the shared sta=
te.
> > +When memory blocks are plugged, the driver is expected to convert them=
 to
> > +the private state before use. Unless VIRTIO_MEM_F_UNPLUGGED_INACCESSIB=
LE
> > +has been negotiated, the driver is expected to convert them back to th=
e
> > +shared state before unplugging.
>
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is a legacy leftover.
>
> Should we rather enforce that such devices in CoCo environments MUST adve=
rtise
> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE? So they would always have to be conv=
erted 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 r=
eally
> apply: if the device has VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, but the gue=
st
> driver does not support it, the expectation is that feature validation fa=
ils
> (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 / Me=
mory Device / Feature bits}
> >  configuration is valid and corresponds to an ACPI PXM.
> >  \item[VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE (1)] The driver is not allow=
ed to
> >  access unplugged memory. \footnote{On platforms with memory properties=
 that
> > -might get modified implicitly on memory access, this feature is expect=
ed 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 gu=
est
> >  to enter suspended state (deep sleep, suspend-to-RAM).
> >  \end{description}
> > @@ -176,9 +189,15 @@ \subsection{Device Initialization}\label{Device Ty=
pes / Memory Device / Device I
> >  The device MUST NOT modify memory or memory properties of plugged memo=
ry
> >  blocks during device reset.
> >
> > +On platforms with a shared/private memory property, the device MUST NO=
T
> > +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 platfor=
m
> >  supports suspending (deep sleep, suspend-to-RAM) with plugged memory b=
locks.
> >
> > +The device SHOULD offer VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE if the pla=
tform
> > +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 w=
ants
> > @@ -256,6 +275,15 @@ \subsection{Device Operation}\label{sec:Device Typ=
es / 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 bl=
ocks.
> >
> > +On platforms with a shared/private memory property, the driver MUST co=
nvert
> > +plugged memory blocks to the private state before initializing or othe=
rwise
> > +using them.
> > +
> > +On platforms with a shared/private memory property, the driver MUST co=
nvert
> > +memory blocks to the shared state before requesting to unplug them (fo=
r
> > +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 m=
emory
> 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 p=
rivate
> 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/[email protected]/2026050=
[email protected]/