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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
