msr.txt 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153
  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. At present, this facility is only used by kvmclock.
  6. Custom MSRs have a range reserved for them, that goes from
  7. 0x4b564d00 to 0x4b564dff. There are MSRs outside this area,
  8. but they are deprecated and their use is discouraged.
  9. Custom MSR list
  10. --------
  11. The current supported Custom MSR list is:
  12. MSR_KVM_WALL_CLOCK_NEW: 0x4b564d00
  13. data: 4-byte alignment physical address of a memory area which must be
  14. in guest RAM. This memory is expected to hold a copy of the following
  15. structure:
  16. struct pvclock_wall_clock {
  17. u32 version;
  18. u32 sec;
  19. u32 nsec;
  20. } __attribute__((__packed__));
  21. whose data will be filled in by the hypervisor. The hypervisor is only
  22. guaranteed to update this data at the moment of MSR write.
  23. Users that want to reliably query this information more than once have
  24. to write more than once to this MSR. Fields have the following meanings:
  25. version: guest has to check version before and after grabbing
  26. time information and check that they are both equal and even.
  27. An odd version indicates an in-progress update.
  28. sec: number of seconds for wallclock.
  29. nsec: number of nanoseconds for wallclock.
  30. Note that although MSRs are per-CPU entities, the effect of this
  31. particular MSR is global.
  32. Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
  33. leaf prior to usage.
  34. MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01
  35. data: 4-byte aligned physical address of a memory area which must be in
  36. guest RAM, plus an enable bit in bit 0. This memory is expected to hold
  37. a copy of the following structure:
  38. struct pvclock_vcpu_time_info {
  39. u32 version;
  40. u32 pad0;
  41. u64 tsc_timestamp;
  42. u64 system_time;
  43. u32 tsc_to_system_mul;
  44. s8 tsc_shift;
  45. u8 flags;
  46. u8 pad[2];
  47. } __attribute__((__packed__)); /* 32 bytes */
  48. whose data will be filled in by the hypervisor periodically. Only one
  49. write, or registration, is needed for each VCPU. The interval between
  50. updates of this structure is arbitrary and implementation-dependent.
  51. The hypervisor may update this structure at any time it sees fit until
  52. anything with bit0 == 0 is written to it.
  53. Fields have the following meanings:
  54. version: guest has to check version before and after grabbing
  55. time information and check that they are both equal and even.
  56. An odd version indicates an in-progress update.
  57. tsc_timestamp: the tsc value at the current VCPU at the time
  58. of the update of this structure. Guests can subtract this value
  59. from current tsc to derive a notion of elapsed time since the
  60. structure update.
  61. system_time: a host notion of monotonic time, including sleep
  62. time at the time this structure was last updated. Unit is
  63. nanoseconds.
  64. tsc_to_system_mul: a function of the tsc frequency. One has
  65. to multiply any tsc-related quantity by this value to get
  66. a value in nanoseconds, besides dividing by 2^tsc_shift
  67. tsc_shift: cycle to nanosecond divider, as a power of two, to
  68. allow for shift rights. One has to shift right any tsc-related
  69. quantity by this value to get a value in nanoseconds, besides
  70. multiplying by tsc_to_system_mul.
  71. With this information, guests can derive per-CPU time by
  72. doing:
  73. time = (current_tsc - tsc_timestamp)
  74. time = (time * tsc_to_system_mul) >> tsc_shift
  75. time = time + system_time
  76. flags: bits in this field indicate extended capabilities
  77. coordinated between the guest and the hypervisor. Availability
  78. of specific flags has to be checked in 0x40000001 cpuid leaf.
  79. Current flags are:
  80. flag bit | cpuid bit | meaning
  81. -------------------------------------------------------------
  82. | | time measures taken across
  83. 0 | 24 | multiple cpus are guaranteed to
  84. | | be monotonic
  85. -------------------------------------------------------------
  86. Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
  87. leaf prior to usage.
  88. MSR_KVM_WALL_CLOCK: 0x11
  89. data and functioning: same as MSR_KVM_WALL_CLOCK_NEW. Use that instead.
  90. This MSR falls outside the reserved KVM range and may be removed in the
  91. future. Its usage is deprecated.
  92. Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
  93. leaf prior to usage.
  94. MSR_KVM_SYSTEM_TIME: 0x12
  95. data and functioning: same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead.
  96. This MSR falls outside the reserved KVM range and may be removed in the
  97. future. Its usage is deprecated.
  98. Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
  99. leaf prior to usage.
  100. The suggested algorithm for detecting kvmclock presence is then:
  101. if (!kvm_para_available()) /* refer to cpuid.txt */
  102. return NON_PRESENT;
  103. flags = cpuid_eax(0x40000001);
  104. if (flags & 3) {
  105. msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW;
  106. msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW;
  107. return PRESENT;
  108. } else if (flags & 0) {
  109. msr_kvm_system_time = MSR_KVM_SYSTEM_TIME;
  110. msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK;
  111. return PRESENT;
  112. } else
  113. return NON_PRESENT;