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

[Kiryl Shutsemau <kas@kernel.org>]

On Tue, Jan 13, 2026 at 12:22:33PM -0600, Pratik R. Sampat wrote:
> 
> 
> On 1/13/26 11:53 AM, Kiryl Shutsemau wrote:
> > On Tue, Jan 13, 2026 at 11:10:21AM -0600, Pratik R. Sampat wrote:
> >>
> >>
> >> 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.
> > 
> > This seems to be one-of-many possible ways of VMM to get guest terminated.
> > DoS is not in something confidential computing aims to prevent.
> > 
> >> However, if this flow is not a concern to begin with then I could
> >> probably just drop this patch?
> > 
> > Yes, please.
> 
> Putting more thought into it, memory unacceptance on remove may be required
> after all at least for SNP platforms.
> 
> Consider a scenario:
> * Guest accepts a GPA say G1, mapped to a host physical address H1.
> * We attempt to hot-remove the memory. If the guest does not unaccept the memory
>   now then G1 to H1 mapping within the RMP will still exist.
> * Then if the hypervisor later hot-adds the memory to G1, it will be now mapped
>   to H3 and this new mapping will be accepted.
> 
> This will essentially mean that we have 2 RMP entries: One for H1 and another
> for H3 mapped for G1 which are both validated / accepted which can then be
> swapped at will and compromise integrity.

I don't know much about SEV, but I assume RMP is similar to PAMT in TDX
where TDX module maintains metadata for host physical memory.

What side problems do you for guest here?

I probably miss something, but it seems to be VMM problem, no? I mean if
VMM doesn't update RMP on replacing one HPA to another for the GPA, it
is bug in VMM housekeeping. Guest is not responsible for this.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov