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

[David Hildenbrand (Arm)]

On 4/10/26 03:05, Duan, Zhenzhong wrote:
> 
> 
>> -----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:
>>>
>>>
>>>
>> how
>>>
>>> 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?

Once we have in-place conversion with guest_memfd, the punching will be
required, though.

-- 
Cheers,

David