About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / virtual / kvm / msr.txt




Custom Search

Based on kernel version 3.16. Page generated on 2014-08-06 21:41 EST.

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

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.