diff options
author | Luis R. Rodriguez <mcgrof@suse.com> | 2015-02-13 01:43:40 -0500 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2015-02-13 01:45:44 -0500 |
commit | a2e199915725e666772dd077dbffbef154e58096 (patch) | |
tree | 10b984c9ca4f9c1957808d39603ee095f0c7d71a /Documentation/ia64/paravirt_ops.txt | |
parent | d9bab50aa46ce46dd4537d455eb13b200cdac516 (diff) |
virtual: Documentation: simplify and generalize paravirt_ops.txt
The general documentation we have for pv_ops is currenty present
on the IA64 docs, but since this documentation covers IA64 xen
enablement and IA64 Xen support got ripped out a while ago
through commit d52eefb47 present since v3.14-rc1 lets just
simplify, generalize and move the pv_ops documentation to a
shared place.
Cc: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Alok Kataria <akataria@vmware.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xenproject.org
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'Documentation/ia64/paravirt_ops.txt')
-rw-r--r-- | Documentation/ia64/paravirt_ops.txt | 137 |
1 files changed, 0 insertions, 137 deletions
diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt deleted file mode 100644 index 39ded02ec33f..000000000000 --- a/Documentation/ia64/paravirt_ops.txt +++ /dev/null | |||
@@ -1,137 +0,0 @@ | |||
1 | Paravirt_ops on IA64 | ||
2 | ==================== | ||
3 | 21 May 2008, Isaku Yamahata <yamahata@valinux.co.jp> | ||
4 | |||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | The aim of this documentation is to help with maintainability and/or to | ||
9 | encourage people to use paravirt_ops/IA64. | ||
10 | |||
11 | paravirt_ops (pv_ops in short) is a way for virtualization support of | ||
12 | Linux kernel on x86. Several ways for virtualization support were | ||
13 | proposed, paravirt_ops is the winner. | ||
14 | On the other hand, now there are also several IA64 virtualization | ||
15 | technologies like kvm/IA64, xen/IA64 and many other academic IA64 | ||
16 | hypervisors so that it is good to add generic virtualization | ||
17 | infrastructure on Linux/IA64. | ||
18 | |||
19 | |||
20 | What is paravirt_ops? | ||
21 | --------------------- | ||
22 | It has been developed on x86 as virtualization support via API, not ABI. | ||
23 | It allows each hypervisor to override operations which are important for | ||
24 | hypervisors at API level. And it allows a single kernel binary to run on | ||
25 | all supported execution environments including native machine. | ||
26 | Essentially paravirt_ops is a set of function pointers which represent | ||
27 | operations corresponding to low level sensitive instructions and high | ||
28 | level functionalities in various area. But one significant difference | ||
29 | from usual function pointer table is that it allows optimization with | ||
30 | binary patch. It is because some of these operations are very | ||
31 | performance sensitive and indirect call overhead is not negligible. | ||
32 | With binary patch, indirect C function call can be transformed into | ||
33 | direct C function call or in-place execution to eliminate the overhead. | ||
34 | |||
35 | Thus, operations of paravirt_ops are classified into three categories. | ||
36 | - simple indirect call | ||
37 | These operations correspond to high level functionality so that the | ||
38 | overhead of indirect call isn't very important. | ||
39 | |||
40 | - indirect call which allows optimization with binary patch | ||
41 | Usually these operations correspond to low level instructions. They | ||
42 | are called frequently and performance critical. So the overhead is | ||
43 | very important. | ||
44 | |||
45 | - a set of macros for hand written assembly code | ||
46 | Hand written assembly codes (.S files) also need paravirtualization | ||
47 | because they include sensitive instructions or some of code paths in | ||
48 | them are very performance critical. | ||
49 | |||
50 | |||
51 | The relation to the IA64 machine vector | ||
52 | --------------------------------------- | ||
53 | Linux/IA64 has the IA64 machine vector functionality which allows the | ||
54 | kernel to switch implementations (e.g. initialization, ipi, dma api...) | ||
55 | depending on executing platform. | ||
56 | We can replace some implementations very easily defining a new machine | ||
57 | vector. Thus another approach for virtualization support would be | ||
58 | enhancing the machine vector functionality. | ||
59 | But paravirt_ops approach was taken because | ||
60 | - virtualization support needs wider support than machine vector does. | ||
61 | e.g. low level instruction paravirtualization. It must be | ||
62 | initialized very early before platform detection. | ||
63 | |||
64 | - virtualization support needs more functionality like binary patch. | ||
65 | Probably the calling overhead might not be very large compared to the | ||
66 | emulation overhead of virtualization. However in the native case, the | ||
67 | overhead should be eliminated completely. | ||
68 | A single kernel binary should run on each environment including native, | ||
69 | and the overhead of paravirt_ops on native environment should be as | ||
70 | small as possible. | ||
71 | |||
72 | - for full virtualization technology, e.g. KVM/IA64 or | ||
73 | Xen/IA64 HVM domain, the result would be | ||
74 | (the emulated platform machine vector. probably dig) + (pv_ops). | ||
75 | This means that the virtualization support layer should be under | ||
76 | the machine vector layer. | ||
77 | |||
78 | Possibly it might be better to move some function pointers from | ||
79 | paravirt_ops to machine vector. In fact, Xen domU case utilizes both | ||
80 | pv_ops and machine vector. | ||
81 | |||
82 | |||
83 | IA64 paravirt_ops | ||
84 | ----------------- | ||
85 | In this section, the concrete paravirt_ops will be discussed. | ||
86 | Because of the architecture difference between ia64 and x86, the | ||
87 | resulting set of functions is very different from x86 pv_ops. | ||
88 | |||
89 | - C function pointer tables | ||
90 | They are not very performance critical so that simple C indirect | ||
91 | function call is acceptable. The following structures are defined at | ||
92 | this moment. For details see linux/include/asm-ia64/paravirt.h | ||
93 | - struct pv_info | ||
94 | This structure describes the execution environment. | ||
95 | - struct pv_init_ops | ||
96 | This structure describes the various initialization hooks. | ||
97 | - struct pv_iosapic_ops | ||
98 | This structure describes hooks to iosapic operations. | ||
99 | - struct pv_irq_ops | ||
100 | This structure describes hooks to irq related operations | ||
101 | - struct pv_time_op | ||
102 | This structure describes hooks to steal time accounting. | ||
103 | |||
104 | - a set of indirect calls which need optimization | ||
105 | Currently this class of functions correspond to a subset of IA64 | ||
106 | intrinsics. At this moment the optimization with binary patch isn't | ||
107 | implemented yet. | ||
108 | struct pv_cpu_op is defined. For details see | ||
109 | linux/include/asm-ia64/paravirt_privop.h | ||
110 | Mostly they correspond to ia64 intrinsics 1-to-1. | ||
111 | Caveat: Now they are defined as C indirect function pointers, but in | ||
112 | order to support binary patch optimization, they will be changed | ||
113 | using GCC extended inline assembly code. | ||
114 | |||
115 | - a set of macros for hand written assembly code (.S files) | ||
116 | For maintenance purpose, the taken approach for .S files is single | ||
117 | source code and compile multiple times with different macros definitions. | ||
118 | Each pv_ops instance must define those macros to compile. | ||
119 | The important thing here is that sensitive, but non-privileged | ||
120 | instructions must be paravirtualized and that some privileged | ||
121 | instructions also need paravirtualization for reasonable performance. | ||
122 | Developers who modify .S files must be aware of that. At this moment | ||
123 | an easy checker is implemented to detect paravirtualization breakage. | ||
124 | But it doesn't cover all the cases. | ||
125 | |||
126 | Sometimes this set of macros is called pv_cpu_asm_op. But there is no | ||
127 | corresponding structure in the source code. | ||
128 | Those macros mostly 1:1 correspond to a subset of privileged | ||
129 | instructions. See linux/include/asm-ia64/native/inst.h. | ||
130 | And some functions written in assembly also need to be overrided so | ||
131 | that each pv_ops instance have to define some macros. Again see | ||
132 | linux/include/asm-ia64/native/inst.h. | ||
133 | |||
134 | |||
135 | Those structures must be initialized very early before start_kernel. | ||
136 | Probably initialized in head.S using multi entry point or some other trick. | ||
137 | For native case implementation see linux/arch/ia64/kernel/paravirt.c. | ||