msr.txt 9.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267
  1. KVM-specific MSRs.
  2. Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
  3. =====================================================
  4. KVM makes use of some custom MSRs to service some requests.
  5. Custom MSRs have a range reserved for them, that goes from
  6. 0x4b564d00 to 0x4b564dff. There are MSRs outside this area,
  7. but they are deprecated and their use is discouraged.
  8. Custom MSR list
  9. --------
  10. The current supported Custom MSR list is:
  11. MSR_KVM_WALL_CLOCK_NEW: 0x4b564d00
  12. data: 4-byte alignment physical address of a memory area which must be
  13. in guest RAM. This memory is expected to hold a copy of the following
  14. structure:
  15. struct pvclock_wall_clock {
  16. u32 version;
  17. u32 sec;
  18. u32 nsec;
  19. } __attribute__((__packed__));
  20. whose data will be filled in by the hypervisor. The hypervisor is only
  21. guaranteed to update this data at the moment of MSR write.
  22. Users that want to reliably query this information more than once have
  23. to write more than once to this MSR. Fields have the following meanings:
  24. version: guest has to check version before and after grabbing
  25. time information and check that they are both equal and even.
  26. An odd version indicates an in-progress update.
  27. sec: number of seconds for wallclock at time of boot.
  28. nsec: number of nanoseconds for wallclock at time of boot.
  29. In order to get the current wallclock time, the system_time from
  30. MSR_KVM_SYSTEM_TIME_NEW needs to be added.
  31. Note that although MSRs are per-CPU entities, the effect of this
  32. particular MSR is global.
  33. Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
  34. leaf prior to usage.
  35. MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01
  36. data: 4-byte aligned physical address of a memory area which must be in
  37. guest RAM, plus an enable bit in bit 0. This memory is expected to hold
  38. a copy of the following structure:
  39. struct pvclock_vcpu_time_info {
  40. u32 version;
  41. u32 pad0;
  42. u64 tsc_timestamp;
  43. u64 system_time;
  44. u32 tsc_to_system_mul;
  45. s8 tsc_shift;
  46. u8 flags;
  47. u8 pad[2];
  48. } __attribute__((__packed__)); /* 32 bytes */
  49. whose data will be filled in by the hypervisor periodically. Only one
  50. write, or registration, is needed for each VCPU. The interval between
  51. updates of this structure is arbitrary and implementation-dependent.
  52. The hypervisor may update this structure at any time it sees fit until
  53. anything with bit0 == 0 is written to it.
  54. Fields have the following meanings:
  55. version: guest has to check version before and after grabbing
  56. time information and check that they are both equal and even.
  57. An odd version indicates an in-progress update.
  58. tsc_timestamp: the tsc value at the current VCPU at the time
  59. of the update of this structure. Guests can subtract this value
  60. from current tsc to derive a notion of elapsed time since the
  61. structure update.
  62. system_time: a host notion of monotonic time, including sleep
  63. time at the time this structure was last updated. Unit is
  64. nanoseconds.
  65. tsc_to_system_mul: multiplier to be used when converting
  66. tsc-related quantity to nanoseconds
  67. tsc_shift: shift to be used when converting tsc-related
  68. quantity to nanoseconds. This shift will ensure that
  69. multiplication with tsc_to_system_mul does not overflow.
  70. A positive value denotes a left shift, a negative value
  71. a right shift.
  72. The conversion from tsc to nanoseconds involves an additional
  73. right shift by 32 bits. With this information, guests can
  74. derive per-CPU time by doing:
  75. time = (current_tsc - tsc_timestamp)
  76. if (tsc_shift >= 0)
  77. time <<= tsc_shift;
  78. else
  79. time >>= -tsc_shift;
  80. time = (time * tsc_to_system_mul) >> 32
  81. time = time + system_time
  82. flags: bits in this field indicate extended capabilities
  83. coordinated between the guest and the hypervisor. Availability
  84. of specific flags has to be checked in 0x40000001 cpuid leaf.
  85. Current flags are:
  86. flag bit | cpuid bit | meaning
  87. -------------------------------------------------------------
  88. | | time measures taken across
  89. 0 | 24 | multiple cpus are guaranteed to
  90. | | be monotonic
  91. -------------------------------------------------------------
  92. | | guest vcpu has been paused by
  93. 1 | N/A | the host
  94. | | See 4.70 in api.txt
  95. -------------------------------------------------------------
  96. Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
  97. leaf prior to usage.
  98. MSR_KVM_WALL_CLOCK: 0x11
  99. data and functioning: same as MSR_KVM_WALL_CLOCK_NEW. Use that instead.
  100. This MSR falls outside the reserved KVM range and may be removed in the
  101. future. Its usage is deprecated.
  102. Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
  103. leaf prior to usage.
  104. MSR_KVM_SYSTEM_TIME: 0x12
  105. data and functioning: same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead.
  106. This MSR falls outside the reserved KVM range and may be removed in the
  107. future. Its usage is deprecated.
  108. Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
  109. leaf prior to usage.
  110. The suggested algorithm for detecting kvmclock presence is then:
  111. if (!kvm_para_available()) /* refer to cpuid.txt */
  112. return NON_PRESENT;
  113. flags = cpuid_eax(0x40000001);
  114. if (flags & 3) {
  115. msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW;
  116. msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW;
  117. return PRESENT;
  118. } else if (flags & 0) {
  119. msr_kvm_system_time = MSR_KVM_SYSTEM_TIME;
  120. msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK;
  121. return PRESENT;
  122. } else
  123. return NON_PRESENT;
  124. MSR_KVM_ASYNC_PF_EN: 0x4b564d02
  125. data: Bits 63-6 hold 64-byte aligned physical address of a
  126. 64 byte memory area which must be in guest RAM and must be
  127. zeroed. Bits 5-2 are reserved and should be zero. Bit 0 is 1
  128. when asynchronous page faults are enabled on the vcpu 0 when
  129. disabled. Bit 1 is 1 if asynchronous page faults can be injected
  130. when vcpu is in cpl == 0.
  131. First 4 byte of 64 byte memory location will be written to by
  132. the hypervisor at the time of asynchronous page fault (APF)
  133. injection to indicate type of asynchronous page fault. Value
  134. of 1 means that the page referred to by the page fault is not
  135. present. Value 2 means that the page is now available. Disabling
  136. interrupt inhibits APFs. Guest must not enable interrupt
  137. before the reason is read, or it may be overwritten by another
  138. APF. Since APF uses the same exception vector as regular page
  139. fault guest must reset the reason to 0 before it does
  140. something that can generate normal page fault. If during page
  141. fault APF reason is 0 it means that this is regular page
  142. fault.
  143. During delivery of type 1 APF cr2 contains a token that will
  144. be used to notify a guest when missing page becomes
  145. available. When page becomes available type 2 APF is sent with
  146. cr2 set to the token associated with the page. There is special
  147. kind of token 0xffffffff which tells vcpu that it should wake
  148. up all processes waiting for APFs and no individual type 2 APFs
  149. will be sent.
  150. If APF is disabled while there are outstanding APFs, they will
  151. not be delivered.
  152. Currently type 2 APF will be always delivered on the same vcpu as
  153. type 1 was, but guest should not rely on that.
  154. MSR_KVM_STEAL_TIME: 0x4b564d03
  155. data: 64-byte alignment physical address of a memory area which must be
  156. in guest RAM, plus an enable bit in bit 0. This memory is expected to
  157. hold a copy of the following structure:
  158. struct kvm_steal_time {
  159. __u64 steal;
  160. __u32 version;
  161. __u32 flags;
  162. __u32 pad[12];
  163. }
  164. whose data will be filled in by the hypervisor periodically. Only one
  165. write, or registration, is needed for each VCPU. The interval between
  166. updates of this structure is arbitrary and implementation-dependent.
  167. The hypervisor may update this structure at any time it sees fit until
  168. anything with bit0 == 0 is written to it. Guest is required to make sure
  169. this structure is initialized to zero.
  170. Fields have the following meanings:
  171. version: a sequence counter. In other words, guest has to check
  172. this field before and after grabbing time information and make
  173. sure they are both equal and even. An odd version indicates an
  174. in-progress update.
  175. flags: At this point, always zero. May be used to indicate
  176. changes in this structure in the future.
  177. steal: the amount of time in which this vCPU did not run, in
  178. nanoseconds. Time during which the vcpu is idle, will not be
  179. reported as steal time.
  180. MSR_KVM_EOI_EN: 0x4b564d04
  181. data: Bit 0 is 1 when PV end of interrupt is enabled on the vcpu; 0
  182. when disabled. Bit 1 is reserved and must be zero. When PV end of
  183. interrupt is enabled (bit 0 set), bits 63-2 hold a 4-byte aligned
  184. physical address of a 4 byte memory area which must be in guest RAM and
  185. must be zeroed.
  186. The first, least significant bit of 4 byte memory location will be
  187. written to by the hypervisor, typically at the time of interrupt
  188. injection. Value of 1 means that guest can skip writing EOI to the apic
  189. (using MSR or MMIO write); instead, it is sufficient to signal
  190. EOI by clearing the bit in guest memory - this location will
  191. later be polled by the hypervisor.
  192. Value of 0 means that the EOI write is required.
  193. It is always safe for the guest to ignore the optimization and perform
  194. the APIC EOI write anyway.
  195. Hypervisor is guaranteed to only modify this least
  196. significant bit while in the current VCPU context, this means that
  197. guest does not need to use either lock prefix or memory ordering
  198. primitives to synchronise with the hypervisor.
  199. However, hypervisor can set and clear this memory bit at any time:
  200. therefore to make sure hypervisor does not interrupt the
  201. guest and clear the least significant bit in the memory area
  202. in the window between guest testing it to detect
  203. whether it can skip EOI apic write and between guest
  204. clearing it to signal EOI to the hypervisor,
  205. guest must both read the least significant bit in the memory area and
  206. clear it using a single CPU instruction, such as test and clear, or
  207. compare and exchange.