1Paravirt_ops on IA64
   3                          21 May 2008, Isaku Yamahata <>
   8The aim of this documentation is to help with maintainability and/or to
   9encourage people to use paravirt_ops/IA64.
  11paravirt_ops (pv_ops in short) is a way for virtualization support of
  12Linux kernel on x86. Several ways for virtualization support were
  13proposed, paravirt_ops is the winner.
  14On the other hand, now there are also several IA64 virtualization
  15technologies like kvm/IA64, xen/IA64 and many other academic IA64
  16hypervisors so that it is good to add generic virtualization
  17infrastructure on Linux/IA64.
  20What is paravirt_ops?
  22It has been developed on x86 as virtualization support via API, not ABI.
  23It allows each hypervisor to override operations which are important for
  24hypervisors at API level. And it allows a single kernel binary to run on
  25all supported execution environments including native machine.
  26Essentially paravirt_ops is a set of function pointers which represent
  27operations corresponding to low level sensitive instructions and high
  28level functionalities in various area. But one significant difference
  29from usual function pointer table is that it allows optimization with
  30binary patch. It is because some of these operations are very
  31performance sensitive and indirect call overhead is not negligible.
  32With binary patch, indirect C function call can be transformed into
  33direct C function call or in-place execution to eliminate the overhead.
  35Thus, 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.
  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.
  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.
  51The relation to the IA64 machine vector
  53Linux/IA64 has the IA64 machine vector functionality which allows the
  54kernel to switch implementations (e.g. initialization, ipi, dma api...)
  55depending on executing platform.
  56We can replace some implementations very easily defining a new machine
  57vector. Thus another approach for virtualization support would be
  58enhancing the machine vector functionality.
  59But 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.
  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.
  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.
  78Possibly it might be better to move some function pointers from
  79paravirt_ops to machine vector. In fact, Xen domU case utilizes both
  80pv_ops and machine vector.
  83IA64 paravirt_ops
  85In this section, the concrete paravirt_ops will be discussed.
  86Because of the architecture difference between ia64 and x86, the
  87resulting set of functions is very different from x86 pv_ops.
  89- C function pointer tables
  90They are not very performance critical so that simple C indirect
  91function call is acceptable. The following structures are defined at
  92this 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.
 104- a set of indirect calls which need optimization
 105Currently this class of functions correspond to a subset of IA64
 106intrinsics. At this moment the optimization with binary patch isn't
 107implemented yet.
 108struct pv_cpu_op is defined. For details see
 110Mostly they correspond to ia64 intrinsics 1-to-1.
 111Caveat: Now they are defined as C indirect function pointers, but in
 112order to support binary patch optimization, they will be changed
 113using GCC extended inline assembly code.
 115- a set of macros for hand written assembly code (.S files)
 116For maintenance purpose, the taken approach for .S files is single
 117source code and compile multiple times with different macros definitions.
 118Each pv_ops instance must define those macros to compile.
 119The important thing here is that sensitive, but non-privileged
 120instructions must be paravirtualized and that some privileged
 121instructions also need paravirtualization for reasonable performance.
 122Developers who modify .S files must be aware of that. At this moment
 123an easy checker is implemented to detect paravirtualization breakage.
 124But it doesn't cover all the cases.
 126Sometimes this set of macros is called pv_cpu_asm_op. But there is no
 127corresponding structure in the source code.
 128Those macros mostly 1:1 correspond to a subset of privileged
 129instructions. See linux/include/asm-ia64/native/inst.h.
 130And some functions written in assembly also need to be overrided so
 131that each pv_ops instance have to define some macros. Again see
 135Those structures must be initialized very early before start_kernel.
 136Probably initialized in head.S using multi entry point or some other trick.
 137For native case implementation see linux/arch/ia64/kernel/paravirt.c.