On 16/11/2017 23:54, Marcelo Tosatti wrote:
> On Mon, Nov 06, 2017 at 05:56:19PM +0100, Paolo Bonzini wrote:
>> The seconds/nanoseconds pair returned from the hypercall is pretty
>> much the same value that is written into struct pvclock_wall_clock,
>> except better because it does not suffer from the y2038 problem.
>>
>> Test that this is the case, in preparation for using
>> KVM_HC_CLOCK_PAIRING in Linux instead of MSR_KVM_WALL_CLOCK_NEW.
>
> Hey Paolo,
>
> Well pvclock_wall_clock has:
>
> struct pvclock_wall_clock {
> u32 version;
> u32 sec;
> u32 nsec;
> u32 sec_hi;
> } __attribute__((__packed__));
Note that sec_hi is only used on ARM, and
Documentation/virtual/kvm/msr.txt says that KVM only writes 12 bytes.
> While the year 2038 bug has an overflow when using a _signed_ integer
> for keeping seconds from Jan 1 1970.
>
> (Thats a 2^31 overflow).
Yeah, that's correct. It's only pvclock_read_wallclock that has a year
2038 bug; that could be fixed as well to use struct timespec64 and only
have a year 2106 bug, but it seemed simpler to make it correct once and
for all.
Paolo
> Did you just infer a year 2038 bug from the "32-bit sec" or there is
> actually a signed integer being used?
>
> Btw, should perform testing with date=2038 and Linux guests... Or are
> you doing that already?
>
> Thanks
>
