Difference between revisions of "Porting the kernel"
Botinki Kira (talk | contribs) m (Robot: Automated text replacement (-VE +container)) |
(Marked this version for translation) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | OpenVZ kernel supports x86, x86_64, IA64, power64, and [[sparc]] architectures as of now. Below are the quick and dirty information about how to port the kernel to yet another architecture. | + | <translate> |
| + | <!--T:1--> | ||
| + | OpenVZ kernel supports x86, x86_64, IA64, power64, [http://community.livejournal.com/openvz/24651.html arm] and [[sparc]] architectures as of now. Below are the quick and dirty information about how to port the kernel to yet another architecture. | ||
| + | <!--T:2--> | ||
* UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of <code>insert_vm_struct()</code> this should be accounted with <code>ub_memory_charge()</code>. Didn't find such thing on sparc64. | * UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of <code>insert_vm_struct()</code> this should be accounted with <code>ub_memory_charge()</code>. Didn't find such thing on sparc64. | ||
| + | <!--T:3--> | ||
* If there are user triggerable <code>printk()</code>'s (related to the user, not the system as a whole) better replace them with <code>ve_printk()</code>. Otherwise user can flood (DoS). minor actually. | * If there are user triggerable <code>printk()</code>'s (related to the user, not the system as a whole) better replace them with <code>ve_printk()</code>. Otherwise user can flood (DoS). minor actually. | ||
| + | <!--T:4--> | ||
* Call to functions <code>find_task_by_pid()</code>, <code>for_each_process()</code> and <code>do_each_thread()</code>/<code>while_each_thread()</code> should be replaced with it's counterparts - <code>find_task_by_pid_XXX()</code>, <code>for_each_process_XXX()</code> and <code>do_each_thread_XXX()</code>/<code>while_each_thread_XXX()</code>, where <code>XXX</code> is either <code>all</code> or <code>ve</code>. Here <code>all</code> means that all system processes in the system will be scanned, while <code>ve</code> means that only the [[container]] accessible from this task (current context - <code>get_exec_env()</code>) will be visible. So you need to decide whether the code in question is about system or user context. | * Call to functions <code>find_task_by_pid()</code>, <code>for_each_process()</code> and <code>do_each_thread()</code>/<code>while_each_thread()</code> should be replaced with it's counterparts - <code>find_task_by_pid_XXX()</code>, <code>for_each_process_XXX()</code> and <code>do_each_thread_XXX()</code>/<code>while_each_thread_XXX()</code>, where <code>XXX</code> is either <code>all</code> or <code>ve</code>. Here <code>all</code> means that all system processes in the system will be scanned, while <code>ve</code> means that only the [[container]] accessible from this task (current context - <code>get_exec_env()</code>) will be visible. So you need to decide whether the code in question is about system or user context. | ||
| + | <!--T:5--> | ||
* <code>task->pid</code> should be changed with <code>virt_pid(task)</code> in some places. The rule is simple: user should see only virtual pids, while kernel operate on global pids. e.g. in signals, virtual pid should be delivered to app. | * <code>task->pid</code> should be changed with <code>virt_pid(task)</code> in some places. The rule is simple: user should see only virtual pids, while kernel operate on global pids. e.g. in signals, virtual pid should be delivered to app. | ||
| + | <!--T:6--> | ||
* In interrupt handlers one need to set global host ([[CT0]]) context. i.e. <code>set_exec_env()</code>, <code>set_exec_ub()</code>. i.e. interrupt handlers are running in CT0 context. | * In interrupt handlers one need to set global host ([[CT0]]) context. i.e. <code>set_exec_env()</code>, <code>set_exec_ub()</code>. i.e. interrupt handlers are running in CT0 context. | ||
| + | <!--T:7--> | ||
* In <code>kernel_thread()</code> one needs to prohibit kernel threads in container. Mostly security related... | * In <code>kernel_thread()</code> one needs to prohibit kernel threads in container. Mostly security related... | ||
| + | <!--T:8--> | ||
* Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current container. | * Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current container. | ||
| + | <!--T:9--> | ||
* <code>utsname</code> should be virtualized. This mostly means that <code>system_utsnames</code> should be replaced with <code>ve_utsname</code>. See any arch code for this. | * <code>utsname</code> should be virtualized. This mostly means that <code>system_utsnames</code> should be replaced with <code>ve_utsname</code>. See any arch code for this. | ||
| + | <!--T:10--> | ||
* Some exports will be required. e.g. <code>show_mem()</code> and probably <code>cpu_khz</code>. Easy. | * Some exports will be required. e.g. <code>show_mem()</code> and probably <code>cpu_khz</code>. Easy. | ||
| + | <!--T:11--> | ||
* Everything else are bugfixes. | * Everything else are bugfixes. | ||
| + | <!--T:12--> | ||
All these are straightforward and really simple, so it should take a few hours to do. | All these are straightforward and really simple, so it should take a few hours to do. | ||
| − | == External links == | + | == External links == <!--T:13--> |
* [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post] | * [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post] | ||
| + | </translate> | ||
[[Category: Kernel internals]] | [[Category: Kernel internals]] | ||
[[Category: Development]] | [[Category: Development]] | ||
Latest revision as of 22:34, 25 December 2015
<translate> OpenVZ kernel supports x86, x86_64, IA64, power64, arm and sparc architectures as of now. Below are the quick and dirty information about how to port the kernel to yet another architecture.
- UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of
insert_vm_struct()this should be accounted withub_memory_charge(). Didn't find such thing on sparc64.
- If there are user triggerable
printk()'s (related to the user, not the system as a whole) better replace them withve_printk(). Otherwise user can flood (DoS). minor actually.
- Call to functions
find_task_by_pid(),for_each_process()anddo_each_thread()/while_each_thread()should be replaced with it's counterparts -find_task_by_pid_XXX(),for_each_process_XXX()anddo_each_thread_XXX()/while_each_thread_XXX(), whereXXXis eitherallorve. Hereallmeans that all system processes in the system will be scanned, whilevemeans that only the container accessible from this task (current context -get_exec_env()) will be visible. So you need to decide whether the code in question is about system or user context.
task->pidshould be changed withvirt_pid(task)in some places. The rule is simple: user should see only virtual pids, while kernel operate on global pids. e.g. in signals, virtual pid should be delivered to app.
- In interrupt handlers one need to set global host (CT0) context. i.e.
set_exec_env(),set_exec_ub(). i.e. interrupt handlers are running in CT0 context.
- In
kernel_thread()one needs to prohibit kernel threads in container. Mostly security related...
- Extend
show_registers()(orshow_regs()) to show current container.
utsnameshould be virtualized. This mostly means thatsystem_utsnamesshould be replaced withve_utsname. See any arch code for this.
- Some exports will be required. e.g.
show_mem()and probablycpu_khz. Easy.
- Everything else are bugfixes.
All these are straightforward and really simple, so it should take a few hours to do.
External links[edit]
</translate>
