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

Hi

On Wed, May 20, 2026 at 7:23=E2=80=AFPM David Hildenbrand (Arm)
<[email protected]> wrote:
>
> On 5/18/26 13:39, Marc-Andr=C3=A9 Lureau wrote:
> > 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 su=
ch
> >>> as AMD SEV-SNP or Intel TDX). Define the device and driver requiremen=
ts
> >>> 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/desc=
ription.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 / M=
emory Device}
> >>>  provides the exact same properties with the exact same semantics for
> >>>  plugged device memory as available for comparable RAM in the same co=
nfiguration.
> >>>
> >>> +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 instr=
uctions
> >>> +or hypercalls.} The device provides unplugged memory in the shared s=
tate.
> >>> +When memory blocks are plugged, the driver is expected to convert th=
em to
> >>> +the private state before use. Unless VIRTIO_MEM_F_UNPLUGGED_INACCESS=
IBLE
> >>> +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 a=
dvertise
> >> VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE? So they would always have to be c=
onverted 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, fo=
r
> 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 hotplugge=
d memory
> >> will appear in the shared state? I have some faint recollection that s=
ome
> >> platforms would start out with new memory in the private state (that t=
hey would
> >> still have to accept before use. But cocneptually, the memory is in th=
e 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/[email protected]/202=
[email protected]/
>
> Okay, that only touches TDX. We really have to be careful here to not doc=
ument
> something that is specific to one platform.
>
> I can try asking some folks in the bi-weekly guest-memfd call in June.

ok, thanks!