uvm_hotplug(9) port masters' FAQ

[Cherry G. Mathew <cherry%zyx.in@localhost>]

Hi Everyone,

Here's an FAQ for port-masters with questions about uvm_hotplug(9).

Please feel free to ask further questions in reply to this email.

-- 
~cherry

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).