Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-31 Thread Avi Kivity

On 05/31/2010 04:49 PM, Glauber Costa wrote:



How are we failing to meet it?  All guests align to at least four bytes.
 

static struct pvclock_wall_clock wall_clock;

Unless there is something that the compiler does that I should take for granted,
there is no alignment directive in there, and it could be anywhere.
   


The compiler will align u32 and larger to 4 bytes on i386 (and align u64 
to 8 bytes on x86_64).


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-31 Thread Glauber Costa
On Sun, May 30, 2010 at 12:14:21PM +0300, Avi Kivity wrote:
> On 05/27/2010 07:02 PM, Glauber Costa wrote:
> >>
> >>>+
> >>>+Custom MSR list
> >>>+
> >>>+
> >>>+The current supported Custom MSR list is:
> >>>+
> >>>+MSR_KVM_WALL_CLOCK:  0x11
> >>>+
> >>>+  data: physical address of a memory area.
> >>Which must be in guest RAM (i.e., don't point it somewhere random
> >>and expect the hypervisor to allocate it for you).
> >>
> >>Must be aligned to 4 bytes (we don't enforce it though).
> >I don't see the reason for it.
> 
> Insurance.
> 
> >If this is a requirement, our own implementation
> >is failing to meet it.
> 
> How are we failing to meet it?  All guests align to at least four bytes.
static struct pvclock_wall_clock wall_clock;

Unless there is something that the compiler does that I should take for granted,
there is no alignment directive in there, and it could be anywhere.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-30 Thread Avi Kivity

On 05/27/2010 07:02 PM, Glauber Costa wrote:



+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area.
   

Which must be in guest RAM (i.e., don't point it somewhere random
and expect the hypervisor to allocate it for you).

Must be aligned to 4 bytes (we don't enforce it though).
 

I don't see the reason for it.
   


Insurance.


If this is a requirement, our own implementation
is failing to meet it.
   


How are we failing to meet it?  All guests align to at least four bytes.

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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Zachary Amsden

On 05/27/2010 02:10 PM, Glauber Costa wrote:

On Thu, May 27, 2010 at 11:02:35AM -1000, Zachary Amsden wrote:
   

On 05/27/2010 10:36 AM, Glauber Costa wrote:
 

On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
   

On 05/27/2010 06:02 AM, Glauber Costa wrote:
 

On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
   

On 05/26/2010 09:04 PM, Glauber Costa wrote:
 

This patch adds a file that documents the usage of KVM-specific
MSRs.

   

Looks good.  A few comments:

 

+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area.
   

Which must be in guest RAM (i.e., don't point it somewhere random
and expect the hypervisor to allocate it for you).

Must be aligned to 4 bytes (we don't enforce it though).
 

I don't see the reason for it.

If this is a requirement, our own implementation
is failing to meet it.
   

It's so the atomic write actually is atomic.
 

Which atomic write? This is the wallclock, we do no atomic writes for
querying it. Not to confuse with system time (the other msr).

   

Stating a 4 -byte
alignment requirement prevents the wall clock from crossing a page
boundary.
 

Yes, but why require it?

reading the wallclock is not a hot path for anybody, is usually done
just once, and crossing a page boundary here does not pose any correctness
issue.
   

Little-endian non-atomic page crossing writes will write the small
part of the wallclock first, so another CPU may observe the
following wallclock sequence:

0x01ff .. 0x0100 .. 0x0200

Big-endian writes also have similar failure:

0x01ff .. 0x02ff .. 0x0200

This won't happen if there is a single instruction write of the wall
clock word.
 

We already specify that users can only trust the value of the wallclock
after we have an even version field.
When we start the update, and during the time of all writes to it,
it is odd, and thus, invalid.
The ABI guarantees to the guest that we'll only bump version
after we're done updating.
   


I guess there is not a point.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Glauber Costa
On Thu, May 27, 2010 at 11:02:35AM -1000, Zachary Amsden wrote:
> On 05/27/2010 10:36 AM, Glauber Costa wrote:
> >On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
> >>On 05/27/2010 06:02 AM, Glauber Costa wrote:
> >>>On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
> On 05/26/2010 09:04 PM, Glauber Costa wrote:
> >This patch adds a file that documents the usage of KVM-specific
> >MSRs.
> >
> Looks good.  A few comments:
> 
> >+
> >+Custom MSR list
> >+
> >+
> >+The current supported Custom MSR list is:
> >+
> >+MSR_KVM_WALL_CLOCK:  0x11
> >+
> >+data: physical address of a memory area.
> Which must be in guest RAM (i.e., don't point it somewhere random
> and expect the hypervisor to allocate it for you).
> 
> Must be aligned to 4 bytes (we don't enforce it though).
> >>>I don't see the reason for it.
> >>>
> >>>If this is a requirement, our own implementation
> >>>is failing to meet it.
> >>It's so the atomic write actually is atomic.
> >Which atomic write? This is the wallclock, we do no atomic writes for
> >querying it. Not to confuse with system time (the other msr).
> >
> >>Stating a 4 -byte
> >>alignment requirement prevents the wall clock from crossing a page
> >>boundary.
> >Yes, but why require it?
> >
> >reading the wallclock is not a hot path for anybody, is usually done
> >just once, and crossing a page boundary here does not pose any correctness
> >issue.
> 
> Little-endian non-atomic page crossing writes will write the small
> part of the wallclock first, so another CPU may observe the
> following wallclock sequence:
> 
> 0x01ff .. 0x0100 .. 0x0200
> 
> Big-endian writes also have similar failure:
> 
> 0x01ff .. 0x02ff .. 0x0200
> 
> This won't happen if there is a single instruction write of the wall
> clock word.

We already specify that users can only trust the value of the wallclock
after we have an even version field.
When we start the update, and during the time of all writes to it,
it is odd, and thus, invalid.
The ABI guarantees to the guest that we'll only bump version
after we're done updating.

So why bother?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Zachary Amsden

On 05/27/2010 10:36 AM, Glauber Costa wrote:

On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
   

On 05/27/2010 06:02 AM, Glauber Costa wrote:
 

On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
   

On 05/26/2010 09:04 PM, Glauber Costa wrote:
 

This patch adds a file that documents the usage of KVM-specific
MSRs.

   

Looks good.  A few comments:

 

+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area.
   

Which must be in guest RAM (i.e., don't point it somewhere random
and expect the hypervisor to allocate it for you).

Must be aligned to 4 bytes (we don't enforce it though).
 

I don't see the reason for it.

If this is a requirement, our own implementation
is failing to meet it.
   

It's so the atomic write actually is atomic.
 

Which atomic write? This is the wallclock, we do no atomic writes for
querying it. Not to confuse with system time (the other msr).

   

Stating a 4 -byte
alignment requirement prevents the wall clock from crossing a page
boundary.
 

Yes, but why require it?

reading the wallclock is not a hot path for anybody, is usually done
just once, and crossing a page boundary here does not pose any correctness
issue.
   


Little-endian non-atomic page crossing writes will write the small part 
of the wallclock first, so another CPU may observe the following 
wallclock sequence:


0x01ff .. 0x0100 .. 0x0200

Big-endian writes also have similar failure:

0x01ff .. 0x02ff .. 0x0200

This won't happen if there is a single instruction write of the wall 
clock word.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Glauber Costa
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
> On 05/27/2010 06:02 AM, Glauber Costa wrote:
> >On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
> >>On 05/26/2010 09:04 PM, Glauber Costa wrote:
> >>>This patch adds a file that documents the usage of KVM-specific
> >>>MSRs.
> >>>
> >>Looks good.  A few comments:
> >>
> >>>+
> >>>+Custom MSR list
> >>>+
> >>>+
> >>>+The current supported Custom MSR list is:
> >>>+
> >>>+MSR_KVM_WALL_CLOCK:  0x11
> >>>+
> >>>+  data: physical address of a memory area.
> >>Which must be in guest RAM (i.e., don't point it somewhere random
> >>and expect the hypervisor to allocate it for you).
> >>
> >>Must be aligned to 4 bytes (we don't enforce it though).
> >I don't see the reason for it.
> >
> >If this is a requirement, our own implementation
> >is failing to meet it.
> 
> It's so the atomic write actually is atomic. 
Which atomic write? This is the wallclock, we do no atomic writes for
querying it. Not to confuse with system time (the other msr).

> Stating a 4 -byte
> alignment requirement prevents the wall clock from crossing a page
> boundary.

Yes, but why require it?

reading the wallclock is not a hot path for anybody, is usually done
just once, and crossing a page boundary here does not pose any correctness
issue.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Zachary Amsden

On 05/27/2010 06:02 AM, Glauber Costa wrote:

On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
   

On 05/26/2010 09:04 PM, Glauber Costa wrote:
 

This patch adds a file that documents the usage of KVM-specific
MSRs.

   

Looks good.  A few comments:

 

+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area.
   

Which must be in guest RAM (i.e., don't point it somewhere random
and expect the hypervisor to allocate it for you).

Must be aligned to 4 bytes (we don't enforce it though).
 

I don't see the reason for it.

If this is a requirement, our own implementation
is failing to meet it.
   


It's so the atomic write actually is atomic.  Stating a 4 -byte 
alignment requirement prevents the wall clock from crossing a page boundary.


Zach

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Glauber Costa
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
> On 05/26/2010 09:04 PM, Glauber Costa wrote:
> >This patch adds a file that documents the usage of KVM-specific
> >MSRs.
> >
> 
> Looks good.  A few comments:
> 
> >+
> >+Custom MSR list
> >+
> >+
> >+The current supported Custom MSR list is:
> >+
> >+MSR_KVM_WALL_CLOCK:  0x11
> >+
> >+data: physical address of a memory area.
> 
> Which must be in guest RAM (i.e., don't point it somewhere random
> and expect the hypervisor to allocate it for you).
> 
> Must be aligned to 4 bytes (we don't enforce it though).
I don't see the reason for it.

If this is a requirement, our own implementation
is failing to meet it.


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-27 Thread Avi Kivity

On 05/26/2010 09:04 PM, Glauber Costa wrote:

This patch adds a file that documents the usage of KVM-specific
MSRs.

   


Looks good.  A few comments:


+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area.


Which must be in guest RAM (i.e., don't point it somewhere random and 
expect the hypervisor to allocate it for you).


Must be aligned to 4 bytes (we don't enforce it though).


+
+MSR_KVM_SYSTEM_TIME: 0x12
+
+   data: physical address of a memory area. This memory is expected to
+   hold a copy of the following structure:
   


In guest RAM.  What are the alignment restrictions?  I don't think we 
can restrict to less than 4 bytes without breaking guests retroactively.



+
+   struct pvclock_vcpu_time_info {
+   u32   version;
+   u32   pad0;
+   u64   tsc_timestamp;
+   u64   system_time;
+   u32   tsc_to_system_mul;
+   s8tsc_shift;
+   u8flags;
+   u8pad[2];
+   } __attribute__((__packed__)); /* 32 bytes */
+
+   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.
+
+   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.
+
+   tsc_timestamp: the tsc value at the current VCPU, at the time
+   of the update of this structure. Guests can subtract this value
+   from current tsc to derive a notion of elapsed time since the
+   structure update.
+
+   system_time: the current system time at the time this structure
+   was last updated. Unit is nanoseconds.
   


What is the baseline for system_time?  Guest boot?


+
+   tsc_to_system_mul: a function of the tsc frequency. One has
+   to multiply any tsc-related quantity by this value to get
+   a value in nanoseconds, besides dividing by 2^tsc_shift
+
+   tsc_shift: cycle to nanosecond divider, as a power of two, to
+   allow for shift rights. One has to shift right any tsc-related
+   quantity by this value to get a value in nanoseconds, besides
+   multiplying by tsc_to_system_mul.
   


Would be good to write down the formula for calculating time here.


+
+   flags: bits in this field indicate extended capabilities
+   coordinated between the guest and the hypervisor. Availability
+   of specific flags has to be checked in 0x4001 cpuid leaf.
+   Refer to cpuid.txt for details.
   


Need to document bit 0 here for completeness.  cpuid.txt documents how 
to discover it, here we document how to use it.



+
+   Availability of this MSR must be checked via bit 0 in 0x401 cpuid
+   leaf prior to usage.
+
+   This MSR falls outside the reserved KVM range, and may be removed in the
+   future. Its usage is deprecated.
+
+MSR_KVM_WALL_CLOCK_NEW:   0x4b564d00
+
+   data and functioning: same as MSR_KVM_WALL_CLOCK. Use this instead.
+
+   Availability of this MSR must be checked via bit 3 in 0x401 cpuid
+   leaf prior to usage.
+
+MSR_KVM_SYSTEM_TIME_NEW:  0x4b564d01
+
+   data and functioning: same as MSR_KVM_SYSTEM_TIME. Use this instead.
+
+   Availability of this MSR must be checked via bit 3 in 0x401 cpuid
+   leaf prior to usage.
+
   


Please detail the suggested algorithm for using the msrs (new then old).



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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-26 Thread Glauber Costa
On Wed, May 26, 2010 at 11:35:03AM -0700, Randy Dunlap wrote:
> On Wed, 26 May 2010 14:04:48 -0400 Glauber Costa wrote:
> 
Thanks Randy.

Update version will follow.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add Documentation/kvm/msr.txt

2010-05-26 Thread Randy Dunlap
On Wed, 26 May 2010 14:04:48 -0400 Glauber Costa wrote:

> This patch adds a file that documents the usage of KVM-specific
> MSRs.
> 
> Signed-off-by: Glauber Costa 
> ---
>  Documentation/kvm/msr.txt |  115 
> +
>  1 files changed, 115 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/kvm/msr.txt
> 
> diff --git a/Documentation/kvm/msr.txt b/Documentation/kvm/msr.txt
> new file mode 100644
> index 000..c5110a2
> --- /dev/null
> +++ b/Documentation/kvm/msr.txt
> @@ -0,0 +1,115 @@
> +KVM-specific MSRs.
> +Glauber Costa , Red Hat Inc, 2010
> +=
> +
> +KVM makes use of some custom MSRs to service some requests.
> +At present, this facility is only used by kvmclock.
> +
> +Custom MSRs have a range reserved for them, that goes from
> +0x4b564d00 to 0x4b564dff. There are MSRs outside this area,
> +but they are deprecated and their use is discouraged.
> +
> +Custom MSR list
> +
> +
> +The current supported Custom MSR list is:
> +
> +MSR_KVM_WALL_CLOCK:  0x11
> +
> + data: physical address of a memory area. This memory is expected to
> + hold a copy of the following structure:
> +
> + struct pvclock_wall_clock {
> + u32   version;
> + u32   sec;
> + u32   nsec;
> + } __attribute__((__packed__));
> +
> + whose data will be filled in by the hypervisor. The hypervisor will only
> + touch this data once, at the moment of MSR write. Users that want to

  Users who want to

I don't get the "only touch this data once" part.
It sounds like the hypervisor will touch  2 times (the odd and the even
writes).  It also sounds like the comment should be more like:
The hypervisor will only update this data at the time of each MSR write.


> + query this information more than once, have to write more than once to

 ^drop the comma

> + this MSR. Fields has the following meaning:

 have  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.
> +
> + sec: number of seconds for wallclock.
> +
> + nsec: number of nanoseconds for wallclock.
> +
> + Note that, although MSRs are per-CPU entities, the effect of this

 ^drop comma

> + particular MSR is global.
> +
> + Availability of this MSR must be checked via bit 0 in 0x401 cpuid
> + leaf prior to usage. 
> +
> + This MSR falls outside the reserved KVM range, and may be removed in the
> + future. Its usage is deprecated.
> +
> +MSR_KVM_SYSTEM_TIME: 0x12
> +
> + data: physical address of a memory area. This memory is expected to
> + hold a copy of the following structure:
> +
> + struct pvclock_vcpu_time_info {
> + u32   version;
> + u32   pad0;
> + u64   tsc_timestamp;
> + u64   system_time;
> + u32   tsc_to_system_mul;
> + s8tsc_shift;
> + u8flags;
> + u8pad[2];
> + } __attribute__((__packed__)); /* 32 bytes */
> +
> + 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.
> +
> + 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.
> +
> + tsc_timestamp: the tsc value at the current VCPU, at the time
> + of the update of this structure. Guests can subtract this value
> + from current tsc to derive a notion of elapsed time since the
> + structure update.
> +
> + system_time: the current system time at the time this structure
> + was last updated. Unit is nanoseconds.
> +
> + tsc_to_system_mul: a function of the tsc frequency. One has
> + to multiply any tsc-related quantity by this value to get
> + a value in nanoseconds, besides dividing by 2^tsc_shift
> +
> + tsc_shift: cycle to nanosecond divider, as a power of two, to
> + allow for shift rights. One has to shift right any tsc-related
> + quantity by this value to get a value in nanoseconds, besides
> + multiplying by tsc_to_system_mul.
> +
> + flags: bits in this field indicate extended capabilities
> + coordinated between the guest and the hypervisor. Availability
> + of specific flags has to be checked in 0x4

[PATCH] Add Documentation/kvm/msr.txt

2010-05-26 Thread Glauber Costa
This patch adds a file that documents the usage of KVM-specific
MSRs.

Signed-off-by: Glauber Costa 
---
 Documentation/kvm/msr.txt |  115 +
 1 files changed, 115 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/kvm/msr.txt

diff --git a/Documentation/kvm/msr.txt b/Documentation/kvm/msr.txt
new file mode 100644
index 000..c5110a2
--- /dev/null
+++ b/Documentation/kvm/msr.txt
@@ -0,0 +1,115 @@
+KVM-specific MSRs.
+Glauber Costa , Red Hat Inc, 2010
+=
+
+KVM makes use of some custom MSRs to service some requests.
+At present, this facility is only used by kvmclock.
+
+Custom MSRs have a range reserved for them, that goes from
+0x4b564d00 to 0x4b564dff. There are MSRs outside this area,
+but they are deprecated and their use is discouraged.
+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK:  0x11
+
+   data: physical address of a memory area. This memory is expected to
+   hold a copy of the following structure:
+
+   struct pvclock_wall_clock {
+   u32   version;
+   u32   sec;
+   u32   nsec;
+   } __attribute__((__packed__));
+
+   whose data will be filled in by the hypervisor. The hypervisor will only
+   touch this data once, at the moment of MSR write. Users that want to
+   query this information more than once, have to write more than once to
+   this MSR. Fields has the following meaning:
+
+   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.
+
+   sec: number of seconds for wallclock.
+
+   nsec: number of nanoseconds for wallclock.
+
+   Note that, although MSRs are per-CPU entities, the effect of this
+   particular MSR is global.
+
+   Availability of this MSR must be checked via bit 0 in 0x401 cpuid
+   leaf prior to usage. 
+
+   This MSR falls outside the reserved KVM range, and may be removed in the
+   future. Its usage is deprecated.
+
+MSR_KVM_SYSTEM_TIME: 0x12
+
+   data: physical address of a memory area. This memory is expected to
+   hold a copy of the following structure:
+
+   struct pvclock_vcpu_time_info {
+   u32   version;
+   u32   pad0;
+   u64   tsc_timestamp;
+   u64   system_time;
+   u32   tsc_to_system_mul;
+   s8tsc_shift;
+   u8flags;
+   u8pad[2];
+   } __attribute__((__packed__)); /* 32 bytes */
+
+   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.
+
+   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.
+
+   tsc_timestamp: the tsc value at the current VCPU, at the time
+   of the update of this structure. Guests can subtract this value
+   from current tsc to derive a notion of elapsed time since the
+   structure update.
+
+   system_time: the current system time at the time this structure
+   was last updated. Unit is nanoseconds.
+
+   tsc_to_system_mul: a function of the tsc frequency. One has
+   to multiply any tsc-related quantity by this value to get
+   a value in nanoseconds, besides dividing by 2^tsc_shift
+
+   tsc_shift: cycle to nanosecond divider, as a power of two, to
+   allow for shift rights. One has to shift right any tsc-related
+   quantity by this value to get a value in nanoseconds, besides
+   multiplying by tsc_to_system_mul.
+
+   flags: bits in this field indicate extended capabilities
+   coordinated between the guest and the hypervisor. Availability
+   of specific flags has to be checked in 0x4001 cpuid leaf.
+   Refer to cpuid.txt for details.
+
+   Availability of this MSR must be checked via bit 0 in 0x401 cpuid
+   leaf prior to usage. 
+
+   This MSR falls outside the reserved KVM range, and may be removed in the
+   future. Its usage is deprecated.
+
+MSR_KVM_WALL_CLOCK_NEW:   0x4b564d00
+
+   data and functioning: same as MSR_KVM_WALL_CLOCK. Use this instead.
+
+   Availability of this MSR must be checked via bit 3 in 0x401 cpuid
+   leaf prior to usage. 
+
+MSR_KVM_SYSTEM_TIME_NEW:  0x4b564d01
+
+   data and functioning: same as MSR_KVM_SYSTEM_TIME. Use this instead.
+
+   Ava