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

[Duan, Zhenzhong]

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

Thanks
Zhenzhong