Re: [PATCH v2 10/11] vmware: set cpu capabilities during platform initialization

2017-04-13 Thread Alok Kataria
On Thu, 2017-04-13 at 12:11 +0200, Juergen Gross wrote: > There is no need to set the same capabilities for each cpu > individually. This can be done for all cpus in platform initialization. Looks reasonable to me. Acked-by: Alok Kataria Thanks, Alok > > Cc: Alok Kataria

Re: [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN)

2016-11-10 Thread Alok Kataria
ing dmesg output for his affected 4 virtual > sockets, 1 core per socket VM: > > [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 CPUID: 2 > [Firmware Bug]: CPU1: Using firmware package id 1 instead of 2 > > > Reported-and-tested-by: "Charles (Chas) Williams"

Re: Regression in intel_powerclamp, due to cpu whitelist removal

2016-10-19 Thread Alok Kataria
On Wed, 2016-10-19 at 20:45 -0700, Jacob Pan wrote: > On Tue, 18 Oct 2016 14:20:49 + > Alok Kataria wrote: > > > Hi Jacob, Zhang, > > > > One of your recent commit "thermal/powerclamp: remove cpu > > whitelist” [1], has caused a regression in the

Regression in intel_powerclamp, due to cpu whitelist removal

2016-10-18 Thread Alok Kataria
Hi Jacob, Zhang, One of your recent commit "thermal/powerclamp: remove cpu whitelist” [1], has caused a regression in the kernel. That commit changed powerclamp_probe from requiring all of the following features: X86_FEATURE_NONSTOP_TSC X86_FEATURE_CONSTANT_TSC X86_FEATURE_MWAIT X86_FEATURE_

Re: RFC: Fix kdump failed with 'notsc'

2016-06-24 Thread Alok Kataria
gt; > # The last log is raised by calibrate_delay(), which calls > calibrate_delay_converge() to compute the lpj value. > > # So far, I don't know why the jiffies stays the same. > # But I found two methods can avoid this problem。 > > 1)specify the 'lpj=' with

Re: [Patch RESEND] x86: don't rely on VMWare emulating PAT MSR correctly

2015-01-18 Thread Alok Kataria
Juergen, thanks for following up on this. X86 maintainers - If it helps let me also confirm that without this patch the latest kernels *always* crash on VMware guest running HWv10 and earlier. Please include the fix at your earliest. Thanks, Alok On Mon, 2015-01-19 at 06:05 +0100, Juergen Gro

Re: [PATCH] x86: don't rely on VMWare emulating PAT MSR correctly

2014-12-16 Thread Alok Kataria
Hi, On Tue, 2014-12-16 at 10:58 +0100, Juergen Gross wrote: > VMWare seems not to emulate the PAT MSR correctly: reaeding > MSR_IA32_CR_PAT returns 0 even after writing another value to it. > > Detect this bug and don't use the read value if it is 0. > > Commit bd809af16e3ab1f8d55b3e2928c47c67e2

[tip:x86/urgent] x86, doc: Add an entry in MAINTAINERS for arch/ x86/kernel/cpu/vmware.c

2013-09-04 Thread tip-bot for Alok Kataria
Commit-ID: 4488e09b4582c3d9cae1601351e26584e208d877 Gitweb: http://git.kernel.org/tip/4488e09b4582c3d9cae1601351e26584e208d877 Author: Alok Kataria AuthorDate: Wed, 4 Sep 2013 14:23:41 +0530 Committer: H. Peter Anvin CommitDate: Wed, 4 Sep 2013 22:00:04 -0700 x86, doc: Add an entry in

Re: [PATCH] Add an entry in MAINTAINERS for VMware's hypervisor interface

2013-09-04 Thread Alok Kataria
On Wed, 2013-09-04 at 10:16 -0700, Joe Perches wrote: > On Wed, 2013-09-04 at 14:23 +0530, Alok Kataria wrote: > > Hey, > > > > This change adds an entry to the maintainers file to explicitly state > > that any changes to vmware.c should be sent to the authors of th

[tip:x86/urgent] x86, doc: Add an entry in MAINTAINERS for arch/ x86/kernel/cpu/vmware.c

2013-09-04 Thread tip-bot for Alok Kataria
Commit-ID: db14e78a61691888ded5896da5f171d662a4d2bd Gitweb: http://git.kernel.org/tip/db14e78a61691888ded5896da5f171d662a4d2bd Author: Alok Kataria AuthorDate: Wed, 4 Sep 2013 14:23:41 +0530 Committer: H. Peter Anvin CommitDate: Wed, 4 Sep 2013 04:49:07 -0700 x86, doc: Add an entry in

[PATCH] Add an entry in MAINTAINERS for VMware's hypervisor interface

2013-09-04 Thread Alok Kataria
e but were not directed to me, someone else made me aware of those changes. It could be that my use of different SOB lines "Alok N Kataria" vs "Alok Kataria" confuses get_maintainer.pl, but adding this entry in MAINTAINERS should solve the problem at hand. For one of the

Re: [PATCH] x86, Allow x2apic without IR on VMware platform.

2013-01-22 Thread Alok Kataria
Hi Peter, Ingo, Can you please consider this patch, it allows linux guests to use x2apic when running on VMware platform. Thanks, Alok On Thu, 2013-01-17 at 15:44 -0800, Alok Kataria wrote: > Please consider this patch to allow x2apic without IR support when > running on VMware pl

[PATCH] x86, Allow x2apic without IR on VMware platform.

2013-01-17 Thread Alok Kataria
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 This patch updates x2apic initializaition code to allow x2apic on VMware platform even witho

ARCH_FREE_PTE_NR 5350 on x86_64

2007-10-14 Thread Alok kataria
Hi, Looking at the tlb_flush code path and its co-relation with ARCH_FREE_PTE_NR, on x86-64 architecture. I think we still don't use the ARCH_FREE_PTE_NR of 5350 as the caching value for the mmu_gathers structure, instead fallback to using 506 due to some typo errors in the code. Found this link