similar to: [PATCH] x86/vmware: Read tsc_khz only once - at boot time

On Thu, 27 Oct 2016, Alexey Makhalov wrote: > [RESEND PATCH 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu() Please don't do that. RESEND is a keyword, when the same patch (series) is sent again without any modification vs. the first patch (series). A possible reason to do so is when a patch (series) fell through the cracks and the author wants to bring it to attention again for the

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =

I believe our trademark guidelines say we aren't supposed to use VMware as a noun to mean a product, only to mean the company. So we can say "running on VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" is wrong. There is supposedly some good legal reason for this related to keeping our trademark. On Tue, 25 Oct 2016 22:26:00 -0700,

I believe our trademark guidelines say we aren't supposed to use VMware as a noun to mean a product, only to mean the company. So we can say "running on VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" is wrong. There is supposedly some good legal reason for this related to keeping our trademark. On Tue, 25 Oct 2016 22:26:00 -0700,

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the hypervisor for it and skip this APIC calibration loop. Signed-off-by: Renat Valiullin <rvaliullin at

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the hypervisor for it and skip this APIC calibration loop. Signed-off-by: Renat Valiullin <rvaliullin at

This patchset includes several VMware guest improvements: Alexey Makhalov (3): x86/vmware: Use tsc_khz value for calibrate_cpu() x86/vmware: Add basic paravirt ops support x86/vmware: Add paravirt sched clock Documentation/kernel-parameters.txt | 4 +++ arch/x86/kernel/cpu/vmware.c | 51 +++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) -- 2.10.1

This patchset includes several VMware guest improvements: Alexey Makhalov (3): x86/vmware: Use tsc_khz value for calibrate_cpu() x86/vmware: Add basic paravirt ops support x86/vmware: Add paravirt sched clock Documentation/kernel-parameters.txt | 4 +++ arch/x86/kernel/cpu/vmware.c | 51 +++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) -- 2.10.1

Thanks Thomas for the valuable comments. Changelog for the updated patchset: v1->v2 - Update pvinfo.name. v2->v3 - Address comments from Thomas G, * Created separate function: vmware_sched_clock_setup() (patch 3/3) * Updated commit descriptions for 1/3 and 3/3 Alexey Makhalov (3): x86/vmware: Use tsc_khz value for calibrate_cpu() x86/vmware: Add basic paravirt ops support

Thanks Thomas for the valuable comments. Changelog for the updated patchset: v1->v2 - Update pvinfo.name. v2->v3 - Address comments from Thomas G, * Created separate function: vmware_sched_clock_setup() (patch 3/3) * Updated commit descriptions for 1/3 and 3/3 Alexey Makhalov (3): x86/vmware: Use tsc_khz value for calibrate_cpu() x86/vmware: Add basic paravirt ops support

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified version of native_sched_clock() without ring buffer of mult/shift/offset triplets and preempt toggling. Since VMware hypervisor provides constant tsc we can use constant mult/shift/offset triplet calculated at boot time. no-vmw-sched-clock kernel parameter is added to switch back to the native_sched_clock() implementation.

Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified version of native_sched_clock() without ring buffer of mult/shift/offset triplets and preempt toggling. Since VMware hypervisor provides constant tsc we can use constant mult/shift/offset triplet calculated at boot time. no-vmw-sched-clock kernel parameter is added to disable the paravirt sched clock. Signed-off-by: Alexey

Add basic paravirt support: 1. set pv_info.name to "VMware" to have proper boot log message Booting paravirtualized kernel on VMware instead of "... on bare hardware" 2. set pv_cpu_ops.io_delay() to empty function - paravirt_nop() to avoid vm-exits on IO delays. Signed-off-by: Alexey Makhalov <amakhalov at vmware.com> Acked-by: Alok N Kataria <akataria at

Add basic paravirt support: 1. set pv_info.name to "VMware hypervisor" to have proper boot log message Booting paravirtualized kernel on VMware hypervisor instead of "... on bare hardware" 2. set pv_cpu_ops.io_delay() to empty function - paravirt_nop() to avoid vm-exits on IO delays. Signed-off-by: Alexey Makhalov <amakhalov at vmware.com> Acked-by: Alok N

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

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

Lguest currently requires a TSC, which breaks older machines and Matt Mackall who boots the host with "notsc". In addition, there is no good solution to changing TSC speeds (informing all the guests about the TSC impending change before it happens would be a great deal of code and have issues with disobedient guests). This patch makes the host determine if the TSC is both constant and

On Thu, 27 Oct 2016, Alexey Makhalov wrote: > Set pv_time_ops.sched_clock to vmware_sched_clock(). Please do not describe WHAT the patch does, describe why. Describe the problem you are solving. I can see from the patch > + pv_time_ops.sched_clock = vmware_sched_clock; that you set pv_time_ops.sched_clock to vmware_sched_clock(). > It is simplified > version of