similar to: [PATCH] kvm: move kvmclock initialization inside kvm_guest_init

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

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

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..4bc1be5 100644

<font size=2 face="sans-serif">Hi</font> <br> <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>

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

Passing '-cpu host' is meant to cause qemu to pass the same CPUID flags from the host up to the appliance. The major benefit of this is that the appliance can use all CPU features available to optimize eg. checksumming, crypto, RAID XOR operations, zero fill. However in practice this can cause strange problems on some hardware: https://bugzilla.redhat.com/show_bug.cgi?id=870071 This

Currently we use pv-ops to tell linux not to do anything on io_delay. While the basic idea is good IMHO, I don't see why we would need pv-ops for that. The io delay function already has a switch that can do nothing if you're so inclined. So here's a patch (stacked on top of the previous pv-ops series) that removes the io delay pv-ops hook and just sets the native io delay variable

Currently we use pv-ops to tell linux not to do anything on io_delay. While the basic idea is good IMHO, I don't see why we would need pv-ops for that. The io delay function already has a switch that can do nothing if you're so inclined. So here's a patch (stacked on top of the previous pv-ops series) that removes the io delay pv-ops hook and just sets the native io delay variable

On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: > On 25/05/2019 10:22, Nadav Amit wrote: > > diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h > > index 946f8f1f1efc..3a156e63c57d 100644 > > --- a/arch/x86/include/asm/paravirt_types.h > > +++ b/arch/x86/include/asm/paravirt_types.h > > @@ -211,6 +211,12 @@

On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: > On 25/05/2019 10:22, Nadav Amit wrote: > > diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h > > index 946f8f1f1efc..3a156e63c57d 100644 > > --- a/arch/x86/include/asm/paravirt_types.h > > +++ b/arch/x86/include/asm/paravirt_types.h > > @@ -211,6 +211,12 @@

Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c

Hi Steve, On 2019/12/17 22:40, Steven Price wrote: > On Tue, Dec 17, 2019 at 01:55:49PM +0000, yezengruan at huawei.com wrote: >> From: Zengruan Ye <yezengruan at huawei.com> >> >> Support the vcpu_is_preempted() functionality under KVM/arm64. This will >> enhance lock performance on overcommitted hosts (more runnable vcpus >> than physical cpus in the

On 2017-11-16 17:53, Thomas Gleixner wrote: > On Thu, 16 Nov 2017, Quan Xu wrote: >> On 2017-11-16 06:03, Thomas Gleixner wrote: >> --- a/drivers/cpuidle/cpuidle.c >> +++ b/drivers/cpuidle/cpuidle.c >> @@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, >> struct cpuidle_driver *drv, >> ??????????????? target_state =