version 1.1, 2016/12/29 16:54:37
|
version 1.2, 2016/12/29 16:59:58
|
Line 1
|
Line 1
|
# [[!template id=man name=uvm_hotplug section=9]] port-masters' FAQ. |
# [[!template id=man name=uvm_hotplug section=9]] port-masters' FAQ. |
|
|
1. Why does it matter? |
1. Why does it matter? |
|
|
As a port maintainer any architecture that needs to use the virtual memory |
As a port maintainer any architecture that needs to use the virtual memory |
sub-system of NetBSD aka uvm is affected by the |
sub-system of NetBSD aka uvm is affected by the |
[[!template id=man name=uvm_hotplug section=9]] change. |
[[!template id=man name=uvm_hotplug section=9]] change. |
|
|
Early boot code of every port is affected. Global variables: |
Early boot code of every port is affected. Global variables: |
struct vm_physseg vm_physmem; |
struct vm_physseg vm_physmem; |
int vm_nphysmem; |
int vm_nphysmem; |
are no longer visible. They need to be replaced by appropriate |
are no longer visible. They need to be replaced by appropriate |
accessor calls in [[!template id=man name=uvm_hotplug section=9]] |
accessor calls in [[!template id=man name=uvm_hotplug section=9]] |
|
|
These calls are documented as "Utility Functions" in the |
These calls are documented as "Utility Functions" in the |
[[!template id=man name=uvm_hotplug section=9]] manual. |
[[!template id=man name=uvm_hotplug section=9]] manual. |
|
|
|
The "switchover" CVS commit log is here: |
|
[http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html](http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html) |
|
|
The "switchover" CVS commit log is here: |
2. What files may be affected? |
[http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html](http://mail-index.netbsd.org/source-changes/2016/12/23/msg080110.html) |
|
|
|
|
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. |
|
|
2. What files may be affected? |
But this may not be a exhaustive list. Any other files that deals with pmap and |
|
stealing pages might also be affected. |
|
|
In most of the architectures the "sys/arch/<arch_name>/<arch_name>/machdep.c" |
3. What does it do ? |
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 |
[[!template id=man name=uvm_hotplug section=9]] manages the previously exposed "vm_physmem" static array which |
stealing pages might also be affected. |
used to keep track of the memory segments. |
|
|
3. What does it do ? |
In the current implementation, the array has been replaced with a |
|
[[!template id=man name=rbtree section=3]] backing which makes the |
|
data structure dynamic. |
|
|
[[!template id=man name=uvm_hotplug section=9]] manages the previously exposed "vm_physmem" static array which |
An array based implementation is also provided, for backwards |
used to keep track of the memory segments. |
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. |
|
|
In the current implementation, the array has been replaced with a |
4. Why is it needed? |
[[!template id=man name=rbtree section=3]] backing which makes the |
|
data structure dynamic. |
|
|
|
An array based implementation is also provided, for backwards |
With the [[!template id=man name=rbtree section=3]] backing |
compatibility. This is the default implementation and does not provide |
implementation, the list of physical pages |
hot pluggability. It is also used without 'options UVM_HOTPLUG' |
in the system is no longer in a static array and can dynamically |
However the API itself is implementation agnostic. |
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. |
|
|
4. Why is it needed? |
5. What should I do? |
|
|
With the [[!template id=man name=rbtree section=3]] backing |
Review the changes to your port due to this new feature. The changes |
implementation, the list of physical pages |
may have been made without direct knowledge of your port architecture. |
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? |
See if your port has hotpluggable hardware. If it does, write a driver |
|
to use the [[!template id=man name=uvm_hotplug section=9]] api. |
|
|
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 [[!template id=man name=uvm_hotplug section=9]] api. |
|
|
|
An example of [[!template id=man name=uvm_hotplug section=9]] api's |
|
application can be found in |
|
[[!template id=man name=balloon section=4]]. |
|
|
|
|
An example of [[!template id=man name=uvm_hotplug section=9]] api's |
|
application can be found in |
|
[[!template id=man name=balloon section=4]]. |
|
|