Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

[David Hildenbrand (Red Hat)]

On 12/1/25 18:15, Pratik R. Sampat wrote:
> Hi David,
>
> On 11/28/25 3:34 AM, David Hildenbrand (Red Hat) wrote:
> > On 11/27/25 18:40, Kiryl Shutsemau wrote:
> > > On Wed, Nov 26, 2025 at 04:27:29PM -0600, Pratik R. Sampat wrote:
> > > > On 11/26/25 5:12 AM, Kiryl Shutsemau wrote:
> > > > > On Tue, Nov 25, 2025 at 11:57:51AM -0600, Pratik R. Sampat wrote:
> > > > > > The unaccepted memory structure currently only supports accepting memory
> > > > > > present at boot time. The unaccepted table uses a fixed-size bitmap
> > > > > > reserved in memblock based on the initial memory layout, preventing
> > > > > > dynamic addition of memory ranges after boot. This causes guest
> > > > > > termination when memory is hot-added in a secure virtual machine due to
> > > > > > accessing pages that have not transitioned to private before use.
> > > > >
> > > > > How does the hot-pluggable memory look in EFI memory map? I thought
> > > > > hot-pluggable ranges suppose to be declared thare. The cleanest solution
> > > > > would be to have hot-pluggable and unaccepted indicated in EFI memory,
> > > > > so we can size bitmap accordingly upfront.
> > > >
> > > > I'm not quite sure if I fully understand. Do you mean to refer to the
> > > > EFI_MEMORY_HOT_PLUGGABLE attribute that is used for cold plugged boot
> > > > memory? If so, wouldn't it still be desirable to increase the size of
> > > > the bitmap to what was marked as hotpluggable initially?
> > >
> > > I just don't understand how hotpluggable memory presented in EFI memory
> > > map in presence of unaccepted memory. If not-yet-plugged memory marked
> > > as unaccepted we can preallocate bitmap upfront and make unaccepted
> > > memory transparent wrt hotplug.
> > >
> > > BTW, isn't virtio-mem a more attractive target to support than HW-style
> > > hotplug?
> >
> > I would have thought so as well, such that we can just let virtio-mem take care of any acceptance before actually using hotplugged memory (exposing it to the buddy).
> >
> > Likely there is desire to support other hypervisors?
>
> That's true. We are certainly thinking about how the RAM discard manager
> should look like with multiple states to allow guest_memfd and
> virtio-mem to work together.

Right, there is the QEMU side of it as well.

> Since both paths in Linux eventually converge around
> add_memory_resource(), based on some light hacking in QEMU I could see
> similar hotplug behavior for virtio-mem as well.

For virtio-mem it would not be add_memory_resource().

Whenever we would be plugging memory we would be accepting it, and when 
we would be unplugging memory we would unaccept it.

That is, acceptance does not happen at add_memory_resource() time, but 
when virtio-mem asks the device to transition a device block from 
unplugged<->plugged.

That also means that kexec is not a concern, because the device block 
state will reflect whether memory was accepted or not.

So far the theory :)

So it will be very different to DIMM-based hotplug handling.

--
Cheers

David