Along with the uvm_hotplug(9) two new function calls are introduced to help the
consumer of the API to easily plug and unplug memory into the system, they are
aptly named uvm_physseg_plug() and uvm_physseg_unplug().
The existing memory segment handling functions uvm_page_physload(),
uvm_page_physunload() and uvm_page_physunload_force() is expected to be used
only during boot time. Their use beyond this process will result in a panic(9).
Internally, the boot time memory segment handling functions have been re-written
so that these functions are wrapping over the newly introduced plug and unplug
functions. This reduces the complexity of code maintenance.
When a kernel is compiled without options UVM_HOTPLUG, one cannot use the plug
and unplug after uvm_init(9) is done and this would cause a panic(9).
It is interesting to note that the amount of parameters in the new hotplug API
is very minimal and only necessary parameters are taken in.
Also according to Cherry (cherry@) there may be a notion of MD memory
properties, that need representation, storage and access. These are currently
delegated to the “FREELIST” concept, which is insufficient, since it’s a
scalar. Hence FREELIST concept does not exist for hotplug, one of the things he
suggested is a method to abstract “tags”/”attributes” and introduce it in
hotplug.
Boot time only functions
uvm_physseg_t
uvm_page_physload(paddr_t start, paddr_t end, paddr_t avail_start, paddr_t avail_end, int free_list);bool
uvm_page_physunload(uvm_physseg_t upm, int free_list, paddr_t *paddrp);bool
uvm_page_physunload_force(uvm_physseg_t upm, int free_list, paddr_t *paddrp);Hotplug functions
bool
uvm_physseg_plug(paddr_t pfn, size_t npages, uvm_physseg_t *upmp);bool
uvm_physseg_unplug(paddr_t pfn, size_t npages);