similar to: [PATCH 0/5] paravirt clock source patches, #4

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

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

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

If the guest domain has been suspend/resumed or migrated, then the system clock backing the pvclock clocksource may revert to a smaller value (ie, can be non-monotonic across the migration/save-restore). Make sure we zero last_value in that case so that the domain continues to see clock updates. [ I don't know if kvm needs an analogous fix or not. ] Signed-off-by: Jeremy Fitzhardinge

If the guest domain has been suspend/resumed or migrated, then the system clock backing the pvclock clocksource may revert to a smaller value (ie, can be non-monotonic across the migration/save-restore). Make sure we zero last_value in that case so that the domain continues to see clock updates. [ I don't know if kvm needs an analogous fix or not. ] Signed-off-by: Jeremy Fitzhardinge

If the guest domain has been suspend/resumed or migrated, then the system clock backing the pvclock clocksource may revert to a smaller value (ie, can be non-monotonic across the migration/save-restore). Make sure we zero last_value in that case so that the domain continues to see clock updates. [ I don't know if kvm needs an analogous fix or not. ] Signed-off-by: Jeremy Fitzhardinge

On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote: > On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > 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: > > > > I read the comment three more times and

On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote: > On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > 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: > > > > I read the comment three more times and

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

Create include/asm-ia64/pvclock-abi.h to compile which contains the same definitions of include/asm-x86/pvclock-abi.h because ia64/xen uses same structure. Hopefully include/asm-x86/pvclock-abi.h would be moved to somewhere more generic. Another approach is to include include/asm-x86/pvclock-abi.h from include/asm-ia64/pvclock-abi.h. But this would break if x86 header files are moved under

Create include/asm-ia64/pvclock-abi.h to compile which contains the same definitions of include/asm-x86/pvclock-abi.h because ia64/xen uses same structure. Hopefully include/asm-x86/pvclock-abi.h would be moved to somewhere more generic. Another approach is to include include/asm-x86/pvclock-abi.h from include/asm-ia64/pvclock-abi.h. But this would break if x86 header files are moved under

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,

In 780427f0e11 (Indicate that clock was set in the pvclock gtod notifier), logic was added to pass a CLOCK_WAS_SET notification to the pvclock notifier chain. While that patch added a action flag returned from accumulate_nsecs_to_secs(), it only uses the returned value in one location, and not in the logarithmic accumulation. This means if a leap second triggered during the logarithmic

It seems that VCPU system time 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 =