search for: tsc_timestamp

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_system_time was called before vmx_do_resume, which caused the vcpu_info time structure t...

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

...ime.c --- a/xen/arch/x86/time.c Tue Nov 18 14:34:14 2008 +0800 +++ b/xen/arch/x86/time.c Fri Nov 21 17:34:15 2008 +0800 @@ -689,7 +689,6 @@ wmb(); (*version)++; } - void update_vcpu_system_time(struct vcpu *v) { struct cpu_time *t; @@ -703,7 +702,6 @@ if ( u->tsc_timestamp == t->local_tsc_stamp ) return; - version_update_begin(&u->version); u->tsc_timestamp = t->local_tsc_stamp; @@ -713,14 +711,19 @@ version_update_end(&u->version); } - void update_domain_wallclock_time(struct domain *d) { spin_lock(&...

...d then suddenly agree again every > time the pvclock data is updated. Yes. > Is there a reason to do it this way? Since pvclock updates which update system_timestamp are expensive (must stop all vcpus), they should be avoided. So only HW TSC counts, and used as offset against vcpu's tsc_timestamp.

...d then suddenly agree again every > time the pvclock data is updated. Yes. > Is there a reason to do it this way? Since pvclock updates which update system_timestamp are expensive (must stop all vcpus), they should be avoided. So only HW TSC counts, and used as offset against vcpu's tsc_timestamp.

flight 18092 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18092/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail pass in 18090 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass

...me isn''t monotonic (using 3.0.4). It seems it might be correlated to when a VCPU is switched across real CPUs but I haven''t conclusively proved that. But e.g.: { old = { time = { version = 0x4ec pad0 = 0xe8e0 tsc_timestamp = 0x22cc8398b7194 system_time = 0xe8e0345d8805 tsc_to_system_mul = 0xd62c0083 tsc_shift = ''\377'' pad1 = [ ''\002'', ''\027'', ''\365'' ] } result...

...08 +0800 @@ -689,7 +689,6 @@ wmb(); (*version)++; } - void update_vcpu_system_time(struct vcpu *v) { struct cpu_time *t; @@ -703,7 +702,6 @@ if ( u->tsc_timestamp == t->local_tsc_stamp ) return; - version_update_begin(&u->version); u->tsc_timestamp = t->local_tsc_stamp; @@ -713,14 +711,19 @@ version_update_end(&u->version); } - void...

...gt; > Yes. > > > Is there a reason to do it this way? > > Since pvclock updates which update system_timestamp are expensive (must stop all vcpus), > they should be avoided. > Fair enough. > So only HW TSC counts makes sense. >, and used as offset against vcpu's tsc_timestamp. > Why don't you just expose CLOCK_MONTONIC_RAW or CLOCK_MONOTONIC_RAW plus suspend time, though? Then you would actually be tracking a real kernel timekeeping mode, and you wouldn't need all this complicated offsetting work to avoid accidentally going backwards.

...e it starts updating the fields and raises it again + * (making it even) when it is done. Thus the guest can make sure the + * time values it got are consistent by checking the version before + * and after reading them. + */ + +struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 pad[3]; +} __attribute__((__packed__)); /* 32 bytes */ + +struct pvclock_wall_clock { + u32 version; + u32 sec; + u32 nsec; +} __attribute__((__packed__)); + +#endif /* __ASSEMBLY__ */ +#endif /* ASM_IA64__PVCLOCK_ABI...

...e it starts updating the fields and raises it again + * (making it even) when it is done. Thus the guest can make sure the + * time values it got are consistent by checking the version before + * and after reading them. + */ + +struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 pad[3]; +} __attribute__((__packed__)); /* 32 bytes */ + +struct pvclock_wall_clock { + u32 version; + u32 sec; + u32 nsec; +} __attribute__((__packed__)); + +#endif /* __ASSEMBLY__ */ +#endif /* ASM_IA64__PVCLOCK_ABI...

On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote: > > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > > > > > On Thu, Oct 04, 2018

On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote: > > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > > > > > On Thu, Oct 04, 2018