On 8/27/26 4:18 AM, Duan, Zhenzhong wrote:
>
>
>> -----Original Message-----
>> From: David Hildenbrand (Arm) <[email protected]>
>> Subject: Re: [RFCv2 PATCH 0/6] Support memory hotplug/unplug for TDX CoCo
>> guests
>>
>> On 6/23/26 12:17, Zhenzhong Duan wrote:
>>> This RFCv2 series implements comprehensive support for virtio-mem and ACPI
>>> DIMM memory hotplug/unplug in Intel TDX confidential computing guests.
>>> It explores the start-private memory approach utilizing the native
>>> TDG.MEM.PAGE.RELEASE API.
>>>
>>> We are seeking feedback from Kiryl on the CoCo guest implementation, MM
>>> experts on DIMM & virio-mem memory hotplug integration and broader
>>> virtio/CoCo community input on the overall approach. We are not seeking
>>> x86 maintainer review at this stage.
>>>
>>> == Changes from RFC v1 ==
>>>
>>> - Eliminated callback infrastructure: Dropped plug callback and replaced
>>> unplug callback with platform-level unaccept function into core MM
>>> hotplug and virtio-mem subsystems.
>>> - Added comprehensive bitmap tracking: Introduced a "plugged" bitmap
>>> alongside the unaccepted bitmap to track populated hotplug memory
>>> states to support load_unaligned_zeropad().
>>> - Enhanced SRAT parsing: Extended the EFI stub to parse ACPI SRAT tables
>>> early, ensuring hotpluggable ranges are tracked from initial boot.
>>>
>>> For more introduction about the background or other efforts in community,
>>> please check the RFCv1 cover letter [1].
>>>
>>> == Technical Approach ==
>>>
>>> - Early SRAT Integration: A lightweight EFI stub parser scans ACPI SRAT
>>> tables to identify hotpluggable ranges and adjust bitmap boundaries
>>> early, avoiding the overhead of the full ACPI subsystem.
>>> - Comprehensive Bitmap Tracking: Introduces a "plugged" bitmap right
>>> after the unaccepted bitmap. Both static and hotplugged memory are
>>> tracked, allowing the guest to map which ranges are populated by the
>>> VMM. This prevents acceptance beyond plugged memory boundaries due to
>>> load_unaligned_zeropad() operations.
>>> - Platform Extensibility: Exposes generic CoCo memory interfaces. Other
>>> confidential platforms (like AMD SEV-SNP) can easily adopt this by
>>> hooking their specific mechanisms into arch_unaccept_memory().
>>> - Hotplug & Guest Control: Integrates platform-level unaccept logic
>>> into ACPI hotplug and virtio-mem handlers. Uses TDG.MEM.PAGE.RELEASE
>>> for TDX to explicitly set memory to the "unaccepted" state during
>>> unplug, removing host hole-punching dependencies.
>>> - Kexec Handover: Leverages existing EFI mechanisms to seamlessly hand
>>> over both the extended unaccepted bitmap and the new plugged bitmap
>>> across kexec boundaries.
>>>
>>> == Testing ==
>>>
>>> - dimm and virtio-mem memory hotplug/unplug
>>> - lazy and eager accept
>>> - kexec/kdump with hotplugged memory
>>>
>>> This is tested with Marc-André Lureau's newest qemu series [2]
>>
>> What's the status of this?
>
> Marc's QEMU series is merged.
> For this series, following feedback from Kirill and Pratik, the preferred
> approach
> is updating the UEFI spec for hotplug memory ranges rather than parsing SRAT
> at the EFI stage. Pratik is already pushing this forward, I am currently
> waiting on
> his RFCs. If he hasn't taken over the entire implementation, I can rebase my
> remaining patches on top of his work.
>
> Hi Pratik, have you sent your UEFI RFC out yet? Just wanted to make sure
> I didn't miss your thread.
>
Yes, the RFC has been out for a bit:
https://github.com/tianocore/edk2/pull/12811
The general feedback I've received is that folks are wary of adding yet another
attribute to support hotplug memory (beyond EFI_MEMORY_SP and
EFI_MEMORY_HOT_PLUGGABLE), and that they're waiting for more community input
before moving forward.
In hindsight, I should probably have pinged here as well since folks on this
thread are more adept to review.
Thanks,
--Pratik
