uvm_hotplug(9) port-masters' FAQ.

1. Why does it matter?

   As a port maintainer any architecture that needs to use the virtual memory sub-system of NetBSD aka uvm is affected by the uvm_hotplug(9) change.

   Early boot code of every port is affected. Global variables:

      struct vm_physseg vm_physmem;
      int vm_nphysmem;
   

   are no longer visible. They need to be replaced by appropriate accessor calls in uvm_hotplug(9)

   These calls are documented as "Utility Functions" in the uvm_hotplug(9) manual.

   The "switchover" CVS commit log is here: http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html

2. What files may be affected?

   In most of the architectures the sys/arch/<arch_name>/<arch_name>/machdep.c and sys/arch/<arch_name>/<arch_name>/pmap.c if they exist are usually affected.

   But this may not be a exhaustive list. Any other files that deals with pmap and stealing pages might also be affected.

3. What does it do ?

   uvm_hotplug(9) manages the previously exposed vm_physmem static array which used to keep track of the memory segments.

   In the current implementation, the array has been replaced with a rbtree(3) backing which makes the data structure dynamic.

   An array based implementation is also provided, for backwards compatibility. This is the default implementation and does not provide hot pluggability. It is also used without options UVM_HOTPLUG However the API itself is implementation agnostic.

4. Why is it needed?

   With the rbtree(3) backing implementation, the list of physical pages in the system is no longer in a static array and can dynamically expand or collapse, hence adding new pages to the freelist from newly available RAM / physical memory (plug) or removing retired pages (unplug) via taking them off the freelist and the old vm_physmem.

5. What should I do?

   Review the changes to your port due to this new feature. The changes may have been made without direct knowledge of your port architecture.

   See if your port has hotpluggable hardware. If it does, write a driver to use the uvm_hotplug(9) api.

   An example of uvm_hotplug(9) api's application can be found in balloon(4).