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
