search for: tsc_to_system_mul

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

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

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

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, 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

...t; ktime_get_boot_ns() has frequency correction applied, while > > reading masterclock + TSC offset does not. > > > > So the clock reads differ. > > > > Ah, okay, I finally think I see what's going on. In the kvmclock data > exposed to the guest, tsc_shift and tsc_to_system_mul come from > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from > CLOCK_BOOTTIME. So the kvmclock and kernel clock drift apart at a > rate given by the frequency shift and then suddenly agree again every > time the pvclock data is updated. Yes. > Is there a reason...

...t; ktime_get_boot_ns() has frequency correction applied, while > > reading masterclock + TSC offset does not. > > > > So the clock reads differ. > > > > Ah, okay, I finally think I see what's going on. In the kvmclock data > exposed to the guest, tsc_shift and tsc_to_system_mul come from > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from > CLOCK_BOOTTIME. So the kvmclock and kernel clock drift apart at a > rate given by the frequency shift and then suddenly agree again every > time the pvclock data is updated. Yes. > Is there a reason...

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

...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 = 0xe8e0484568fa tsc = 0x22cc86921ab00 cpu = 0 } new = {...

...tch is > > incorrect? > > ktime_get_boot_ns() has frequency correction applied, while > reading masterclock + TSC offset does not. > > So the clock reads differ. > Ah, okay, I finally think I see what's going on. In the kvmclock data exposed to the guest, tsc_shift and tsc_to_system_mul come from tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from CLOCK_BOOTTIME. So the kvmclock and kernel clock drift apart at a rate given by the frequency shift and then suddenly agree again every time the pvclock data is updated. Is there a reason to do it this way?

...cy correction applied, while > > > reading masterclock + TSC offset does not. > > > > > > So the clock reads differ. > > > > > > > Ah, okay, I finally think I see what's going on. In the kvmclock data > > exposed to the guest, tsc_shift and tsc_to_system_mul come from > > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from > > CLOCK_BOOTTIME. So the kvmclock and kernel clock drift apart at a > > rate given by the frequency shift and then suddenly agree again every > > time the pvclock data is updated. > >...

...t 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_H */ -- 1.6.0.2 -- yamahata

...t 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_H */ -- 1.6.0.2 -- yamahata

...uint32_t version; + uint32_t pad0; + uint64_t tsc_timestamp; /* TSC at last update of time vals. */ + uint64_t system_time; /* Time, in nanosecs, since boot. */ + /* + * Current system time: + * system_time + + * ((((tsc - tsc_timestamp) << tsc_shift) * tsc_to_system_mul) >> 32) + * CPU frequency (Hz): + * ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift + */ + uint32_t tsc_to_system_mul; + int8_t tsc_shift; + int8_t pad1[3]; +}; /* 32 bytes */ +typedef struct vcpu_time_info vcpu_time_info_t; + +struct vcpu_info { + /*...