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

[Duan, Zhenzhong]

>-----Original Message-----
>From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
>Subject: Re: [PATCH 2/2] x86/tdx: Accept hotplugged memory before online
>
>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.

Good to see, thanks for verifying.

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

If guest called set_memory_decrypted() on unplug, QEMU punching
guest_memfd in REQ_UNPLUG is unnecessary as it's already taken during
memory convert. So just to confirm, you want QEMU to take cover the case
when guest failed on set_memory_decrypted() or never called it?

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

Yes.

Thanks
Zhenzhong