[RFC] powerpc/mm/pgtable: Split mappings on hot-unplug

[Bharata B Rao]

On Fri, Feb 2, 2018 at 8:38 AM, Balbir Singh <bsingharora at gmail.com> wrote:

> On Thu, Feb 1, 2018 at 11:48 PM, Balbir Singh <bsingharora at gmail.com>
> wrote:
> > This patch splits the a linear mapping if the hot-unplug range
> > is smaller than the mapping size. The code detects if the mapping
> > needs to be split into a smaller size and if so, uses the stop
> > machine infrastructure to map the current linear mapping with
> > a smaller size mapping. Then the requested area is unmapped.
> >
> > A new API to do a local TLB flush is introduced and exported.
> > This API is used in stop mapping after clearing the larger
> > mapping and before creating the smaller mapping. There is also
> > a check to ensure that we don't overlap with kernel text
> > (the region that is being split) as it could cause the executing
> > text to fault.
> >
> > There are some caveats with this approach, as the unmapping can
> > cause reserved memory area to be freed up (memblock reserved
> > mappings and allocations as well), that can be a problem. There
> > could be a case where radix__map_kernel_page() may fault if the
> > area selected to unmap contains the process page table, this is
> > not a new problem created by the patch, but something to watch
> > out for while testing. The right approach to solving the hot-unplug
> > issue is to make the node/DIMM to be marked hotpluggable so that
> > all the memory in that is movable. Currently there is no method
> > of enforcing the hotpluggable property via libvirt or qemu.
>

In fact QEMU presents all the hotpluggable memory to the guest via
ibm,dynamic-reconfiguration-memory DT node. So guest kernel can easily mark
them as hotpluggable and that is what I tried in my earlier attempts.
However that won't fly with PowerVM for the reason described in
https://patchwork.ozlabs.org/patch/856015/

Regards,
Bharata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20180202/f388739c/attachment.html>