On 10/21/2019 03:23 PM, Anshuman Khandual wrote: > > On 10/18/2019 03:18 PM, Catalin Marinas wrote: >> On Fri, Oct 11, 2019 at 08:26:32AM +0530, Anshuman Khandual wrote: >>> On 10/10/2019 05:04 PM, Catalin Marinas wrote: >>>> Mark Rutland mentioned at some point that, as a preparatory patch to >>>> this series, we'd need to make sure we don't hot-remove memory already >>>> given to the kernel at boot. Any plans here? >>> Hmm, this series just enables platform memory hot remove as required from >>> generic memory hotplug framework. The path here is triggered either from >>> remove_memory() or __remove_memory() which takes physical memory range >>> arguments like (nid, start, size) and do the needful. arch_remove_memory() >>> should never be required to test given memory range for anything including >>> being part of the boot memory. >> Assuming arch_remove_memory() doesn't (cannot) check, is there a risk on > Platform can definitely enumerate boot memory ranges. But checking on it in > arch_remove_memory() which deals with actual procedural details might not be > ideal IMHO. Refusing a requested removal attempt should have been done up in > the call chain. This will require making generic hot plug reject any removal > request which falls within enumerated boot memory. IFAICS currently there is > no generic way to remember which memory came as part of the boot process. > Probably be a new MEMBLOCK flag will do. > >> arm64 that, for example, one removes memory available at boot and then >> kexecs a new kernel? Does the kexec tool present the new kernel with the >> original memory map? > I dont know, probably James can help here. But as I had mentioned earlier, > the callers of remove_memory() should be able to control that. ACPI should > definitely be aware about which ranges were part of boot memory and refrain > from removing any subset, if the platform is known to have problems with > any subsequent kexec operation because the way boot memory map get used. > > Though I am not much aware about kexec internals, it should inherit the > memory state at given point in time accommodating all previous memory hot > and remove operations. As an example cloud environment scenario, memory > resources might have increased or decreased during a guest lifetime, so > when the guest needs to have new OS image why should not it have all the > memory ? I dont know if it's feasible for the guest to expect previous hot > add or remove operations to be played again after the kexec. > > There is another fundamental question here. Is there a notion of a minimum > subset of boot memory which cannot be hot removed no matter what ? If yes, > how that is being conveyed to the kernel currently ? > > The point is that all these need to be established between ACPI, EFI and > kernel. AFAICS this problem is for MM subsystem (including the platform s/is for/is not for/ ^^^^^^^^^^
