Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32

2010-04-24 Thread Faidon Liambotis
Ben Hutchings wrote:
 This is definitely worthwhile but it does involve an ABI bump.  So we
 will probably wait for a convenient time to do that.
I saw that you (well, maks) just bumped the ABI to -5. Ping? :)

Thanks,
Faidon



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32

2010-04-24 Thread maximilian attems
On Sat, Apr 24, 2010 at 11:48:12AM +0300, Faidon Liambotis wrote:
 Ben Hutchings wrote:
  This is definitely worthwhile but it does involve an ABI bump.  So we
  will probably wait for a convenient time to do that.
 I saw that you (well, maks) just bumped the ABI to -5. Ping? :)

tried 3cfc3092f40bc37c57ba556cfd8de4218f2135ab,
ffde22ac53b6d6b1d7206f1172176a667eead778.

none of them apply.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32

2010-04-24 Thread Faidon Liambotis
maximilian attems wrote:
 tried 3cfc3092f40bc37c57ba556cfd8de4218f2135ab,
 ffde22ac53b6d6b1d7206f1172176a667eead778.
 
 none of them apply.
ffde22ac53b6d6b1d7206f1172176a667eead778 (Xen-HVM) applies with some
(manually checked, safe) fuzz/offset.

On top of that, afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d (kvmclock)
applies cleanly also with some minor fuzz.

Alternatively, I've attached a backported kvmclock patch that applies
without Xen-HVM, in case you don't want that.

As for 3cfc3092f40bc37c57ba556cfd8de4218f2135ab (VCPU events), after
applying the previous two, it has one minor conflict that is easily
solvable with a one-liner. If it isn't obvious, I can attach a patch.

(all of the above are tested with a git checkout of 2.6.32, haven't
tried Debian's SVN although I don't expect it to be much different)

Regards,
Faidon



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32

2010-04-17 Thread Ben Hutchings
On Fri, 2010-04-16 at 03:41 +0300, Faidon Liambotis wrote:
 Package: linux-2.6
 Version: 2.6.32-11
 Severity: minor
 Tags: patch, fixed-upstream
 
 Hi,
[...]
 IOW, the API greatly helps KVM live migrations. Without it, there are fair
 chances that after the migration the guest will crash. The API is used by
 qemu-kvm = 0.12.1 and 0.12.3 is currently in squeeze.

This is definitely worthwhile but it does involve an ABI bump.  So we
will probably wait for a convenient time to do that.

[...]
 BTW, while you're at it, perhaps you should have a look at the, also trivial,
 3cfc3092f40bc37c57ba556cfd8de4218f2135ab (“KVM: x86: Add
 KVM_GET/SET_VCPU_EVENTS”) too.

The same goes for that.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Bug#578005: Please consider backporting KVM_GET/SET_CLOCK to 2.6.32

2010-04-15 Thread Faidon Liambotis
Package: linux-2.6
Version: 2.6.32-11
Severity: minor
Tags: patch, fixed-upstream

Hi,

(severity minor since this is something between a bug and a feature request)

Commit afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d, released with 2.6.33, reads:

   [PATCH] KVM: allow userspace to adjust kvmclock offset
   
   When we migrate a kvm guest that uses pvclock between two hosts, we may
   suffer a large skew. This is because there can be significant differences
   between the monotonic clock of the hosts involved. When a new host with
   a much larger monotonic time starts running the guest, the view of time
   will be significantly impacted.
   
   Situation is much worse when we do the opposite, and migrate to a host with
   a smaller monotonic clock.
   
   This proposed ioctl will allow userspace to inform us what is the monotonic
   clock value in the source host, so we can keep the time skew short, and
   more importantly, never goes backwards. Userspace may also need to trigger
   the current data, since from the first migration onwards, it won't be
   reflected by a simple call to clock_gettime() anymore.

IOW, the API greatly helps KVM live migrations. Without it, there are fair
chances that after the migration the guest will crash. The API is used by
qemu-kvm = 0.12.1 and 0.12.3 is currently in squeeze.

The commit came on top of ffde22ac53b6d6b1d7206f1172176a667eead778, “KVM: Xen
PV-on-HVM guest support”, which is totally unrelated in functionality but
makes the patch to not apply cleanly on 2.6.32. The backport modifications are
trivial, the patch ready to be applied on 2.6.32 is attached. The (new) patch
has a diffstat of:
   Documentation/kvm/api.txt   |   36 ++
   arch/x86/include/asm/kvm_host.h |1 
   arch/x86/kvm/x86.c  |   42 +++-
   include/linux/kvm.h |   10 
   4 files changed, 88 insertions(+), 1 deletion(-)

I understand that there are few users needing this; OTOH, the patch is very
simple and the maintainance burden should be much less than other things that
you've pulled, like Xen :)

BTW, while you're at it, perhaps you should have a look at the, also trivial,
3cfc3092f40bc37c57ba556cfd8de4218f2135ab (“KVM: x86: Add
KVM_GET/SET_VCPU_EVENTS”) too.

Thanks,
Faidon
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 5a4bc8c..db3a706 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -593,6 +593,42 @@ struct kvm_irqchip {
 	} chip;
 };
 
+4.27 KVM_GET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (out)
+Returns: 0 on success, -1 on error
+
+Gets the current timestamp of kvmclock as seen by the current guest. In
+conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+	__u64 clock;  /* kvmclock current value */
+	__u32 flags;
+	__u32 pad[9];
+};
+
+4.28 KVM_SET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (in)
+Returns: 0 on success, -1 on error
+
+Sets the current timestamp of kvmclock to the valued specific in its parameter.
+In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+	__u64 clock;  /* kvmclock current value */
+	__u32 flags;
+	__u32 pad[9];
+};
+
 5. The kvm_run structure
 
 Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d838922..d759a1f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -412,6 +412,7 @@ struct kvm_arch{
 	unsigned long irq_sources_bitmap;
 	unsigned long irq_states[KVM_IOAPIC_NUM_PINS];
 	u64 vm_init_tsc;
+	s64 kvmclock_offset;
 };
 
 struct kvm_vm_stat {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ae07d26..adb7912 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -677,7 +677,8 @@ static void kvm_write_guest_time(struct kvm_vcpu *v)
 	/* With all the info we got, fill in the values */
 
 	vcpu-hv_clock.system_time = ts.tv_nsec +
- (NSEC_PER_SEC * (u64)ts.tv_sec);
+ (NSEC_PER_SEC * (u64)ts.tv_sec) + v-kvm-arch.kvmclock_offset;
+
 	/*
 	 * The interface expects us to write an even number signaling that the
 	 * update is finished. Since the guest won't see the intermediate
@@ -1224,6 +1225,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_PIT2:
 	case KVM_CAP_PIT_STATE2:
 	case KVM_CAP_SET_IDENTITY_MAP_ADDR:
+	case KVM_CAP_ADJUST_CLOCK:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -2421,6 +2423,44 @@ long kvm_arch_vm_ioctl(struct file *filp,
 		r = 0;
 		break;
 	}
+	case KVM_SET_CLOCK: {
+		struct timespec now;
+		struct kvm_clock_data user_ns;
+		u64 now_ns;
+		s64 delta;
+
+		r = -EFAULT;
+		if (copy_from_user(user_ns, argp, sizeof(user_ns)))
+