Hi, In this series, I am proposing an steal time implementation for KVM. It is an RFC, so don't be too harsh =] There are two parts of it: the guest and host part. The proposal for the guest part, is to just change the common time accounting, and try to identify at that spot, wether or not we should account any steal time. I considered this idea less cumbersome that trying to cook a clockevents implementation ourselves, since I see little value in it. I am, however, pretty open to suggestions. For the host<->guest communications, I am using a shared page, in the same way as pvclock. Because of that, I am just hijacking pvclock structure anyway. There is a 32-bit field floating by, that gives us enough room for 8 years of steal time (we use msec resolution). The main idea is to timestamp our exit and entry through sched notifiers, and export the value at pvclock updates. This obviously have some disadvantages: by doing this we are giving up futures ideas about only updating this structure once, and even right now, won't work on pinned-smp (since we don't update pvclock if we haven't changed cpus.) But again, it is just an RFC, and I'd like to feel the reception of the idea as a whole. Have a nice review. Glauber Costa (6): change headers preparing for steal time measure time out of guest change kernel accounting to include steal time kvm steal time implementation touch softlockup watchdog tell guest about steal time feature Zachary Amsden (1): Implement getnsboottime kernel API arch/x86/include/asm/kvm_host.h | 2 + arch/x86/include/asm/kvm_para.h | 1 + arch/x86/include/asm/pvclock-abi.h | 4 ++- arch/x86/kernel/kvmclock.c | 38 ++++++++++++++++++++++++++++++++++++ arch/x86/kvm/x86.c | 15 ++++++++++++- include/linux/sched.h | 1 + include/linux/time.h | 1 + kernel/sched.c | 29 +++++++++++++++++++++++++++ kernel/time/timekeeping.c | 27 +++++++++++++++++++++++++ 9 files changed, 115 insertions(+), 3 deletions(-) -- 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
