Mailing List Archive: [PATCH 1/3] include files for kvmclock

[PATCH 1/3] include files for kvmclock

Nov 8, 2007, 2:20 PM

Post #1 of 3 (392 views)

This patch introduces the include files for kvm clock.
They'll be needed for both guest and host part.

Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
---
include/asm-x86/kvm_para.h | 25 +++++++++++++++++++++++++
include/linux/kvm.h | 1 +
include/linux/kvm_para.h | 2 ++
3 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
index c6f3fd8..0f6b813 100644
--- a/include/asm-x86/kvm_para.h
+++ b/include/asm-x86/kvm_para.h
@@ -10,15 +10,40 @@
* paravirtualization, the appropriate feature bit should be checked.
*/
#define KVM_CPUID_FEATURES 0x40000001
+#define KVM_FEATURE_CLOCKSOURCE 0

#ifdef __KERNEL__
#include <asm/processor.h>
+extern void kvmclock_init(void);
+
+/*
+ * Guest has page alignment and padding requirements. At the host, it will
+ * only lead to wasted space at the vcpu struct. For this reason, the struct
+ * is not anonymous
+ */
+union kvm_hv_clock {
+ struct kvm_hv_clock_s {
+ u64 tsc_mult;
+ u64 now_ns;
+ /* That's the wall clock, not the water closet */
+ u64 wc_sec;
+ u64 last_tsc;
+ /* At first, we could use the tsc value as a marker, but Jeremy
+ * well noted that it will cause us locking problems in 32-bit
+ * sys, so we have a special version field */
+ u32 version;
+ } fields;
+ char page_align[PAGE_SIZE];
+};
+

/* This instruction is vmcall. On non-VT architectures, it will generate a
* trap that we will then rewrite to the appropriate instruction.
*/
#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"

+#define KVM_HCALL_REGISTER_CLOCK 1
+
/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
* instruction. The hypervisor may replace it with something else but only the
* instructions are guaranteed to be supported.
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 71d33d6..9862241 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -359,6 +359,7 @@ struct kvm_signal_mask {
#define KVM_CAP_MMU_SHADOW_CACHE_CONTROL 2
#define KVM_CAP_USER_MEMORY 3
#define KVM_CAP_SET_TSS_ADDR 4
+#define KVM_CAP_CLOCKSOURCE 5

/*
* ioctls for VM fds
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index e4db25f..094efc7 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -11,6 +11,8 @@

/* Return values for hypercalls */
#define KVM_ENOSYS 1000
+#define KVM_EINVAL 1019
+#define KVM_ENODEV 1022

#ifdef __KERNEL__
/*
--
1.5.0.6

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/3] include files for kvmclock [ In reply to ]

kraxel at redhat

Nov 9, 2007, 12:37 AM

Post #2 of 3 (366 views)

Permalink

> +/*
> + * Guest has page alignment and padding requirements. At the host, it will
> + * only lead to wasted space at the vcpu struct. For this reason, the struct
> + * is not anonymous
> + */
> +union kvm_hv_clock {
> + struct kvm_hv_clock_s {
> + u64 tsc_mult;
> + u64 now_ns;
> + /* That's the wall clock, not the water closet */
> + u64 wc_sec;
> + u64 last_tsc;
> + /* At first, we could use the tsc value as a marker, but Jeremy
> + * well noted that it will cause us locking problems in 32-bit
> + * sys, so we have a special version field */
> + u32 version;
> + } fields;
> + char page_align[PAGE_SIZE];
> +};

What is the point in using a whole page per vcpu? You probably don't
want struct kvm_hv_clock_s cross a page border. Is that the only reason
or are there other constrains too?

As the kvm clock looks quite simliar to what xen does, how about making
the structs binary-compatible or simply reuse the xen version (struct
vcpu_time_info in xen/interface/xen.h)?

cheers,
Gerd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/3] include files for kvmclock [ In reply to ]

avi at qumranet

Nov 11, 2007, 1:15 AM

Post #3 of 3 (360 views)

Permalink

Gerd Hoffmann wrote:
>> +/*
>> + * Guest has page alignment and padding requirements. At the host, it will
>> + * only lead to wasted space at the vcpu struct. For this reason, the struct
>> + * is not anonymous
>> + */
>> +union kvm_hv_clock {
>> + struct kvm_hv_clock_s {
>> + u64 tsc_mult;
>> + u64 now_ns;
>> + /* That's the wall clock, not the water closet */
>> + u64 wc_sec;
>> + u64 last_tsc;
>> + /* At first, we could use the tsc value as a marker, but Jeremy
>> + * well noted that it will cause us locking problems in 32-bit
>> + * sys, so we have a special version field */
>> + u32 version;
>> + } fields;
>> + char page_align[PAGE_SIZE];
>> +};
>>
>
> What is the point in using a whole page per vcpu? You probably don't
> want struct kvm_hv_clock_s cross a page border. Is that the only reason
> or are there other constrains too?
>

We don't even have the cross-page-boundary constraint.

The real issue is that on i386 physical addresses are 64-bit while
hypercall arguments are 32-bit. A page frame number is 32-bit and so
poses no issues.

I see two workarounds for this:
- make the first hypercall argument a u64 rather than a long (using two
registers on i386)
- use an msr for registering the clock address

The first is more general, while the second has the nice property of
taking care of live migration automatically.

> As the kvm clock looks quite simliar to what xen does, how about making
> the structs binary-compatible or simply reuse the xen version (struct
> vcpu_time_info in xen/interface/xen.h)?
>

If there are no technical issues, I have no objections.

--
error compiling committee.c: too many arguments to function

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/