Re: [PATCH] mm: don't rely on system state to detect hot-plug operations

[Michal Hocko]

On Thu 10-09-20 15:39:00, Oscar Salvador wrote:
> On Thu, Sep 10, 2020 at 02:48:47PM +0200, Michal Hocko wrote:
> > > Is there any actual usecase for a configuration like this? What is the
> > > point to statically define additional memory like this when the same can
> > > be achieved on the same command line?
> 
> Well, for qemu I am not sure, but if David is right, it seems you can face
> the same if you reboot a vm with hotplugged memory.

OK, thanks for the clarification. I was not aware of the reboot.

> Moreover, it seems that the problem we spotted with [1], it was a VM running on
> Promox (KVM).
> The Hypervisor probably said at boot time "Ey, I do have these ACPI devices, care
> to enable them now"?
> 
> As always, there are all sorts of configurations/scenarios out there in the wild.
> 
> > Forgot to ask one more thing. Who is going to online that memory when
> > userspace is not running yet?
> 
> Depends, if you have CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE set or you specify
> memhp_default_online_type=[online,online_*], memory will get onlined right
> after hot-adding stage:
> 
>         /* online pages if requested */
>         if (memhp_default_online_type != MMOP_OFFLINE)
>                 walk_memory_blocks(start, size, NULL, online_memory_block);
> 
> If not, systemd-udev will do the magic once the system is up.

Does that imply that we need udev to scan all existing devices and
reprobe them?
-- 
Michal Hocko
SUSE Labs