Re: [RFCv2 PATCH 0/6] Support memory hotplug/unplug for TDX CoCo guests

["David Hildenbrand (Arm)" <david@kernel.org>]

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?

I am still not sure whether we shouldn't perform acceptance from
move_pfn_range_to_zone() and from memory notifiers / generic_online_page.

In particular, it's unclear to me how virtio-mem (which uses interfaces to
add/remove memory) interacts with unaccept_memory / coco bitmap.

Can we have an overall design view on what happens at which stage when adding /
removing memory through virtio-mem?

-- 
Cheers,

David