similar to: [PATCH v3 00/11] x86: xen cpuid() cleanup

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

There is no need to set the same capabilities for each cpu individually. This can be done for all cpus in platform initialization. Cc: Alok Kataria <akataria at vmware.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at redhat.com> Cc: "H. Peter Anvin" <hpa at zytor.com> Cc: x86 at kernel.org Cc: virtualization at lists.linux-foundation.org

Please consider this patch to allow x2apic without IR support when running on VMware platform. Tested on top of 3.8-rc3. Thanks, Alok -- Allow x2apic without IR on VMware platform. From: Alok N Kataria <akataria at vmware.com> This patch updates x2apic initializaition code to allow x2apic on VMware platform even without interrupt remapping support. The hypervisor_x2apic_available hook

Please consider this patch to allow x2apic without IR support when running on VMware platform. Tested on top of 3.8-rc3. Thanks, Alok -- Allow x2apic without IR on VMware platform. From: Alok N Kataria <akataria at vmware.com> This patch updates x2apic initializaition code to allow x2apic on VMware platform even without interrupt remapping support. The hypervisor_x2apic_available hook

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

>From /xen-unstable.hg/xen/arch/x86/cpu/intel.c if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); if (cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC,

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 =

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

Booting a Xen PVH guest requires a special boot entry as it is mandatory to setup some Xen-specific interfaces rather early. When grub or OVMF are used as boot loaders, however, those will fill the boot parameters in zeropage and there is no longer a need to do something PVH specific in the early boot path. This patch series adds support for that scenario by identifying PVH environment and doing

Hello, This patchset introduces steal time accounting support for the VMware guest. The idea and implementation of guest steal time support is similar to KVM ones and it is based on steal clock. The steal clock is a per CPU structure in a shared memory between hypervisor and guest, initialized by each CPU through hypercall. Steal clock is got updated by the hypervisor and read by the guest. The

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

On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote: > The x86_hyper pointer is only used for checking whether a virtual > device is supporting the hypervisor the system is running on. > > Use an enum for that purpose instead and drop the x86_hyper pointer. > > Cc: kys at microsoft.com > Cc: haiyangz at microsoft.com > Cc: sthemmin at microsoft.com > Cc:

On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote: > The x86_hyper pointer is only used for checking whether a virtual > device is supporting the hypervisor the system is running on. > > Use an enum for that purpose instead and drop the x86_hyper pointer. > > Cc: kys at microsoft.com > Cc: haiyangz at microsoft.com > Cc: sthemmin at microsoft.com > Cc:

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature