similar to: [PATCH 0/3 - resend] kvmclock reboot

This is a note to let you know that I've just added the patch titled x86/hyper-v: Enable PIT shutdown quirk to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-hyper-v-enable-pit-shutdown-quirk.patch and it can be found in the queue-4.19 subdirectory. If you, or anyone

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

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

<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

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 |

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 |

https://bugs.freedesktop.org/show_bug.cgi?id=91738 Bug ID: 91738 Summary: xf86-video-nouveau 1.0.11 will not allow X to start Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

In case of failing due to lack of memory in the system, blkif_init potentially leaves a leak if some of the allocations was sucessfully suceeded. This patch frees the memory allocated, avoiding the leak. Signed-off-by: Glauber de Oliveira Costa <glommer@br.ibm.com> -- glommer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Attached and below are a patch that unifies the shutdown code paths in Xen, including those from EARLY_FAIL. This will facilitate the use of Intel(R) TXT for measured launch by ensuring that all shutdowns will call the necessary hook to tear down the measured environment. It also centralizes any future shutdown-related changes. The patch also postpones clearing the online status APs in