On Sun, 2011-01-30 at 15:19 +0200, Avi Kivity wrote: > On 01/28/2011 09:52 PM, Glauber Costa wrote: > > This patch adds documentation about usage of the newly > > introduced KVM_MSR_STEAL_TIME. > > > > > > + > > +MSR_KVM_STEAL_TIME: 0x4b564d03 > > + > > + data: 4-byte alignment physical address of a memory area which must be > > + in guest RAM, plus an enable bit in bit 0. > > 64-byte aligned: > - avoids wrapping around a page boundary, which may let us optimize > things later on (see kvm_write_guest_cached()). > - gives us 5 more unused bits to enable more options > > > This memory is expected to > > + hold a copy of the following structure: > > + > > + struct kvm_steal_time { > > + __u64 steal; > > + __u32 version; > > + __u32 flags; > > + __u32 pad[6]; > > + } > > + > > + whose data will be filled in by the hypervisor periodically. Only one > > + write, or registration, is needed for each VCPU. The interval between > > + updates of this structure is arbitrary and implementation-dependent. > > + The hypervisor may update this structure at any time it sees fit until > > + anything with bit0 == 0 is written to it. > > + > > + Fields have the following meanings: > > + > > + version: guest has to check version before and after grabbing > > + time information and check that they are both equal and even. > > + An odd version indicates an in-progress update. > > + > > + flags: At this point, always zero. May be used to indicate > > + changes in this structure in the future. > > + > > + steal: the amount of time in which this vCPU did not run, in > > + nanoseconds. > > + > > The guest must initialize the entire 64-byte structure to zero before > enabling the feature. I honestly don't see why. But I also don't see why not... Will update it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html