Difference between revisions of "Porting the kernel"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
m (show_registers otherwise known as show_regs())
(insert_vma_struct -> insert_vm_struct)
Line 1: Line 1:
 
OpenVZ kernel supports x86, x86_64, and IA64 architectures as of now. Below are the quick and dirty information about how to port the  kernel to yet another architecture.
 
OpenVZ kernel supports x86, x86_64, and IA64 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 <code>insert_vma_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.
  
 
* 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.

Revision as of 08:40, 29 August 2006

OpenVZ kernel supports x86, x86_64, and IA64 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 VE 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 (VE0) context. i.e. set_exec_env(), set_exec_ub(). i.e. interrupt handlers are running in VE0 context.
  • In kernel_thread() one needs to prohibit kernel threads in VE. Mostly security related...
  • Extend show_registers() (or show_regs()) to show current VE.
  • 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