search for: kvmclock

since the pv_apic_ops are only present if CONFIG_X86_LOCAL_APIC is compiled in, kvmclock failed to build without this option. This patch fixes this Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kernel/kvmclock.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index ddee040..4b...

Avi, Hope this series is okay now. Thanks for the testing

...her is TSC), > > and using those two clocks to as a "base + offset". > > > > As the comment explains, if you do that, can't guarantee monotonicity. > > > > > actually calling ktime_get_boot_ns() could be non-monotonic > > > with respect to the kvmclock timing. But get_kvmclock_ns() isn't used > > > for VM timing as such -- it's used for the IOCTL interfaces for > > > updating the time offset. So can you explain how my patch is > > > incorrect? > > > > ktime_get_boot_ns() has frequency correction ap...

...her is TSC), > > and using those two clocks to as a "base + offset". > > > > As the comment explains, if you do that, can't guarantee monotonicity. > > > > > actually calling ktime_get_boot_ns() could be non-monotonic > > > with respect to the kvmclock timing. But get_kvmclock_ns() isn't used > > > for VM timing as such -- it's used for the IOCTL interfaces for > > > updating the time offset. So can you explain how my patch is > > > incorrect? > > > > ktime_get_boot_ns() has frequency correction ap...

...hat "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctly to > the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but > L1 isn't notified when the data structure changes, so how the heck is > it supposed to update the kvmclock structure? Well, this kind of works in the the followin way: L1's clocksource is ...

...hat "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctly to > the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but > L1 isn't notified when the data structure changes, so how the heck is > it supposed to update the kvmclock structure? Well, this kind of works in the the followin way: L1's clocksource is ...

...> <br><font size=2 face="sans-serif">I dug various posts and articles on guest time synchronization.</font> <br><font size=2 face="sans-serif">I could not conclude why it might be better to use ntpd in a guest rather than a daemon that reads from kvmclock </font> <br><font size=2 face="sans-serif">and having NTP running on the host only.</font> <br><font size=2 face="sans-serif">(assuming the guest OS is a recent linux and so the clock source is set to the paravirtualized kvm PVclock).</font...

Hi (apologies for the previous post in html - was scrubbed in the list digest) I've dug various posts and articles on host-guest time synchronization. I could not conclude why it might be better to use ntpd in a guest rather than a daemon that reads from kvmclock and having NTP running on the host only (assuming the guest OS is a recent linux and so the clock source is set to the paravirtualized kvm PVclock). any clarifications are welcome, thanks! Edoardo Comar Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales...

...nifests itself as particular operations failing randomly, especially if RAID or crypto is involved. If you enable debugging you would see a kernel stack trace similar to the one shown in the bug above (and possibly many other variations). If you see anything like this, please file a bug. Adding +kvmclock should cause the appliance to use kvm-clock instead of the default (probably tsc). This should improve clock stability on heavily loaded machines, and as far as I know has no downside. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-co...

...t; > > &ka->master_kernel_ns, > > > &ka->master_cycle_now); > > > > > > kvm_get_time_and_clockread() gets those values from > > > do_monotonic_boot(), which, barring bugs, should cause > > > get_kvmclock_ns() to return exactly the same thing as > > > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather > > > roundabout manner. > > > > > > So what am I missing? Is there actually something wrong with my patch? > > > > For the bug mentioned...

...t; > > &ka->master_kernel_ns, > > > &ka->master_cycle_now); > > > > > > kvm_get_time_and_clockread() gets those values from > > > do_monotonic_boot(), which, barring bugs, should cause > > > get_kvmclock_ns() to return exactly the same thing as > > > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather > > > roundabout manner. > > > > > > So what am I missing? Is there actually something wrong with my patch? > > > > For the bug mentioned...

It makes no sense for the clock initialization to be hanging around in setup_32.c when we have a generic kvm guest initialization function available. So, we move kvmclock_init() inside such a function, leading to a cleaner code. Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kernel/kvm.c | 2 ++ arch/x86/kernel/setup_32.c | 4 ---- include/linux/kvm_para.h | 5 +++++ 3 files changed, 7 insertions(+), 4 deletions(-) diff --g...

It makes no sense for the clock initialization to be hanging around in setup_32.c when we have a generic kvm guest initialization function available. So, we move kvmclock_init() inside such a function, leading to a cleaner code. Signed-off-by: Glauber Costa <gcosta at redhat.com> --- arch/x86/kernel/kvm.c | 2 ++ arch/x86/kernel/setup_32.c | 4 ---- include/linux/kvm_para.h | 5 +++++ 3 files changed, 7 insertions(+), 4 deletions(-) diff --g...

...our patch which deletes the code gets the necessary features right, > > sure, go for it. > > > > > The correct way to do it is to hook > > > > Can you expand on the correct way to do it? > > > > > And I don't see how it's even possible to pass kvmclock correctly to > > > the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but > > > L1 isn't notified when the data structure changes, so how the heck is > > > it supposed to update the kvmclock structure? > > > > I don't parse your ques...

...our patch which deletes the code gets the necessary features right, > > sure, go for it. > > > > > The correct way to do it is to hook > > > > Can you expand on the correct way to do it? > > > > > And I don't see how it's even possible to pass kvmclock correctly to > > > the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but > > > L1 isn't notified when the data structure changes, so how the heck is > > > it supposed to update the kvmclock structure? > > > > I don't parse your ques...

...cy. That is "frankenstein" code, could be removed. > That said I'm all for simplification. I'm not sure if we still need to > care about buggy hardware though. What simplification is that again? > > > > And I don't see how it's even possible to pass kvmclock correctly to > > the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but > > L1 isn't notified when the data structure changes, so how the heck is > > it supposed to update the kvmclock structure? > > Well, this kind of works in the the followin way: &...

...ays catchup" and > masterclock-less mode in general are and if we still need them. > > That said I'm all for simplification. I'm not sure if we still need to > care about buggy hardware though. > >> >> And I don't see how it's even possible to pass kvmclock correctly to >> the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but >> L1 isn't notified when the data structure changes, so how the heck is >> it supposed to update the kvmclock structure? > > Well, this kind of works in the the followin way: >...

...gt; is migrated to a different host with a different TSC frequency and TSC >> scaling is not supported by the CPU) we receive an interrupt in L1 (at >> this moment all TSC accesses are emulated which guarantees the >> correctness of the readings), pause all L2 guests, update their kvmclock >> structures with new data (we already know the new TSC frequency) and >> then tell L0 that we're done and it can stop emulating TSC accesses. > > That?s delightful! Does the emulation magic also work for L1 user > mode? As far as I understand - yes, all rdtsc* calls wil...

...gt; is migrated to a different host with a different TSC frequency and TSC >> scaling is not supported by the CPU) we receive an interrupt in L1 (at >> this moment all TSC accesses are emulated which guarantees the >> correctness of the readings), pause all L2 guests, update their kvmclock >> structures with new data (we already know the new TSC frequency) and >> then tell L0 that we're done and it can stop emulating TSC accesses. > > That?s delightful! Does the emulation magic also work for L1 user > mode? As far as I understand - yes, all rdtsc* calls wil...

...is CLOCK_MONOTONIC and the other is TSC), > and using those two clocks to as a "base + offset". > > As the comment explains, if you do that, can't guarantee monotonicity. > > > actually calling ktime_get_boot_ns() could be non-monotonic > > with respect to the kvmclock timing. But get_kvmclock_ns() isn't used > > for VM timing as such -- it's used for the IOCTL interfaces for > > updating the time offset. So can you explain how my patch is > > incorrect? > > ktime_get_boot_ns() has frequency correction applied, while > reading...