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

Hi

On Mon, Apr 20, 2026 at 5:52=E2=80=AFPM Matias Ezequiel Vara Larsen
<[email protected]> wrote:
>
> Hello Marc,
>
> I did a first review of the patch:
>
> On Wed, Apr 15, 2026 at 06:54:35PM +0400, [email protected] wro=
te:
> > 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
>
> 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 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.
> > +
> >  \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.
> > +
>
> 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 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.
> > +
> >  \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.
> > +
> >  The driver MUST NOT request unplug of memory blocks while correspondin=
g memory
> >  or memory properties are still in use.
> >
> > @@ -285,6 +313,11 @@ \subsection{Device Operation}\label{sec:Device Typ=
es / Memory Device / Device Op
> >  The device MAY modify memory of unplugged memory blocks or reset memor=
y
> >  properties of such memory blocks to platform defaults at any time.
> >
> > +On platforms with a shared/private memory property, the device MUST pr=
ovide
> > +unplugged memory blocks in the shared state.  If
> > +VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE has been negotiated, the device MU=
ST
> > +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 memo=
ry
> >  blocks.
> >
> > --
> > 2.53.0
> >
> >
>