Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove

["Pratik R. Sampat" <prsampat@amd.com>]

On 1/13/2026 4:28 AM, Kiryl Shutsemau wrote:
> On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
>> Transition memory to the shared state during a hot-remove operation so
>> that it can be re-used by the hypervisor. This also applies when memory
>> is intended to be hotplugged back in later, as those pages will need to
>> be re-accepted after crossing the trust boundary.
> 
> Hm. What happens when we hot-remove memory that was there at the boot
> and there's bitmap space for it?
> 

While hotplug ranges gotten from SRAT don't seem to overlap with the
conventional ranges in the unaccepted table, EFI_MEMORY_HOT_PLUGGABLE
attribute could indicate boot time memory that could be hot-removed. I
could potentially unset the bitmap first, if the bit exists and then
unaccept.

Similarly, I could also check if the bitmap is large enough to set the
bit before I call arch_accept_memory() (This may not really be needed 
though).

> Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
> the memory from under guest at any time without a warning. Coverting
> memory to shared shouldn't make a difference as along as re-adding the
> same GPA range triggers accept.
> 

That makes sense. The only scenario where we could run into trouble on
SNP platforms is when we redo a qemu device_add after a device_del
without first removing the memory object entirely since same-state
transitions result in guest termination.

This means we must always follow a device_del with an object_del on
removal. Otherwise, the onus would then be on the VMM to transition
the memory back to shared before re-adding it to the guest.

However, if this flow is not a concern to begin with then I could
probably just drop this patch?

--Pratik