Re: [PATCH 2/2] x86/tdx: Accept hotplugged memory before online

[Marc-André Lureau]

Hi

On Thu, Apr 9, 2026 at 5:36 AM Duan, Zhenzhong <zhenzhong.duan@xxxxxxxxx> wrote:
>
>
>
> >-----Original Message-----
> >From: Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx>
> >Subject: Re: [PATCH 2/2] x86/tdx: Accept hotplugged memory before online
> >
> >On Fri, 2026-04-03 at 10:37 +0000, Reshetova, Elena wrote:
> >> > > > So the part about whether a triggered accept succeeds or returns an
> >> > > > already accepted error is already under the control of the host. > >
> >> > > > I.e., if we don't have the zeroing behavior, the host can already > >
> >> > > > cause the page to get zeroed. So I don't think anything is > >
> >> > > > regressed. Both come down to how careful the guest is about what it > >
> >> > > > accepts.
> >> >
> >> > Yes, and my point is that we should not allow guest to freely double
> >> > accepting ever.
> >> > For any use case that requires releasing memory and accepting it > back, it
> >> > should be explicit action by the guest to track that memory > has been
> >> > "released" (under correct and safe conditions) and then it > is ok to accept
> >> > it back (even if it doesnt mean physically accepting > it) and in this case
> >> > it is ok (and even strongly desired) to zero the > page to simulate the
> >> > normal accept behaviour.
> >
> >Hmm, it doesn't seem like you engaged with my point. Or at least I'm not
> >following what is exposed?
> >
> >So I'm going to assume you agree that this procedure would not open up any
> >specific new capabilities for the host that don't exist today. And instead you
> >are just saying that the guest should have infrastructure to not double accept
> >memory in the first place.
> >
> >But the problem here is not that the guest losing track of the accept state
> >actually. It is that the guest relies on the host to actually zap the S-EPT
> >before re-plugging memory at the same physical address space. So the guest is
> >tracking that the memory is released correctly. Better tracking will not help.
> >It relies on host behavior to not hit a double accept.
> >
> >TDX connect will use this "unaccept" seamcall, so I asked Zhenzhong (Cced) how
> >much of what we need for that solution will just get added for TDX connect
> >anyway. It seems like we should make sure the same solution will work for both
> >SNP and TDX and keep the options open at this stage.
>
> For that solution, analog to hotplug, TDX Connect needs a hot-unplug handler to
> use "release" seamcall to unaccept private memory before unplug, that's it. But
> if the zapping S-EPT will not happen in host, I think this "release" seamcall is also
> unnecessary for TDX Connect.
>
> I also have a silly question which I looked over this thread and didn't find answer.
> Do we have to support private memory hotplug, what benefit we get to support it?
> If we only allow shared memory plug/unplug to TD, then we don't need this series.
> Guest decides to convert shared memory to private after plug and do the opposite before unplug.
> This works for both TDX connect and memory unplug as memory release is implicitly triggered
> in memory convert.

I did some successful experiments with modified QEMU & kernel, this
seems to work.

On virtio-mem plug, set_memory_encrypted() makes the memory private +
accepted. On unplug, make it return to shared with
set_memory_decrypted(). QEMU handles REQ_UNPLUG and can punch both
shared & guest_memfd planes (which will TDH.MEM.PAGE.REMOVE).
Re-plugging also works fine.

The virtio spec should probably be updated to explicitly define the
shared state on unplug and the private state on plug, driven by the
guest/driver. Those are KVM memory attributes, I suppose this is
generic enough.