Difference between revisions of "Porting the kernel"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
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 with ub_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 with ve_printk(). Otherwise user can flood (DoS). minor actually.
  • Call to functions find_task_by_pid(), for_each_process() and do_each_thread()/while_each_thread() should be replaced with it's counterparts - find_task_by_pid_XXX(), for_each_process_XXX() and do_each_thread_XXX()/while_each_thread_XXX(), where XXX is either all or ve. Here all means that all system processes in the system will be scanned, while ve means 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->pid should be changed with virt_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() (or show_regs()) to show current container.
  • utsname should be virtualized. This mostly means that system_utsnames should be replaced with ve_utsname. See any arch code for this.
  • Some exports will be required. e.g. show_mem() and probably cpu_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>