Porting the kernel - Revision history

Sergey Bronnikov: Marked this version for translation

2015-12-25T22:34:23Z

Marked this version for translation

Sergey Bronnikov: add 'translate' tags

2015-12-25T22:34:10Z

add 'translate' tags

Alien: added a link about kir's arm port

2008-12-14T23:16:54Z

added a link about kir's arm port

Botinki Kira: Robot: Automated text replacement (-VE +container)

2008-03-11T12:20:35Z

Robot: Automated text replacement (-VE +container)

Botinki Kira: Robot: Automated text replacement (-VE0 +CT0)

2008-03-11T11:44:32Z

Robot: Automated text replacement (-VE0 +CT0)

Kir: kernel internals

2008-01-24T12:52:20Z

kernel internals

Master at 17:26, 13 June 2007

2007-06-13T17:26:59Z

Kir: added more supported platforms

2007-05-11T12:24:16Z

added more supported platforms

Vass: insert_vma_struct -> insert_vm_struct

2006-08-29T08:40:13Z

insert_vma_struct -> insert_vm_struct

Kir: show_registers otherwise known as show_regs()

2006-08-28T11:17:48Z

show_registers otherwise known as show_regs()

@@ Line 1: / Line 1: @@
 <translate>
 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.
 * 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.
 * 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.
 * <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.
 * 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 <code>kernel_thread()</code> one needs to prohibit kernel threads in container. Mostly security related...
 * Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current container.
 * <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.
 * Some exports will be required. e.g. <code>show_mem()</code> and probably <code>cpu_khz</code>. Easy.
 * Everything else are bugfixes.
 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]
 </translate>

@@ Line 1: / Line 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.
@@ Line 25: / Line 26: @@
 == External links ==
 * [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post]
 [[Category: Kernel internals]]
 [[Category: Development]]

← Older revision		Revision as of 23:16, 14 December 2008
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.	+	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.

	* 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.

@@ Line 5: / Line 5: @@
 * 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.
-* 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 [[VE]] 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.
 * <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.
@@ Line 11: / Line 11: @@
 * 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 <code>kernel_thread()</code> one needs to prohibit kernel threads in VE. Mostly security related...
+* In <code>kernel_thread()</code> one needs to prohibit kernel threads in container. Mostly security related...
-* Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current VE.
+* Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current container.
 * <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.

@@ Line 9: / Line 9: @@
 * <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.
-* In interrupt handlers one need to set global host ([[VE0]]) context. i.e. <code>set_exec_env()</code>, <code>set_exec_ub()</code>. i.e. interrupt handlers are running in VE0 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.
 * In <code>kernel_thread()</code> one needs to prohibit kernel threads in VE. Mostly security related...

← Older revision		Revision as of 17:26, 13 June 2007
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.	+	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.

	* 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.

← Older revision		Revision as of 12:24, 11 May 2007
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, 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.

	* 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.