Re: [PATCH] perf/x86: KVM: Disable vPMU support on hybrid CPUs (host PMUs)

["Liang, Kan" <kan.liang@linux.intel.com>]

On 2023-01-19 7:40 p.m., Sean Christopherson wrote:
> Disable KVM support for virtualizing PMUs on hosts with hybrid PMUs until
> KVM gains a sane way to enumeration the hybrid vPMU to userspace and/or
> gains a mechanism to let userspace opt-in to the dangers of exposing a
> hybrid vPMU to KVM guests.
> 
> Virtualizing a hybrid PMU, or at least part of a hybrid PMU, is possible,
> but it requires userspace to pin vCPUs to pCPUs to prevent migrating a
> vCPU between a big core and a little core, requires the VMM to accurately
> enumerate the topology to the guest (if exposing a hybrid CPU to the
> guest), and also requires the VMM to accurately enumerate the vPMU
> capabilities to the guest.

Current kernel only return the common counters to KVM, which is
available on both e-core and p-core. In theory, there should be no
problem with the migration between cores. You don't have to pin vCPU.
The only problem is that you probably can only use the architecture events.

There is nothing wrong for the information provided by the kernel. I
think it should be a KVM issue (my guess is the CPUID enumeration.) we
should fix rather than simply disable the PMU for entire hybrid machines.

Thanks,
Kan
> 
> The last point is especially problematic, as KVM doesn't control which
> pCPU it runs on when enumerating KVM's vPMU capabilities to userspace.
> For now, simply disable vPMU support on hybrid CPUs to avoid inducing
> seemingly random #GPs in guests.
> 
> Reported-by: Jianfeng Gao <jianfeng.gao@intel.com>
> Cc: stable@vger.kernel.org
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Kan Liang <kan.liang@linux.intel.com>
> Cc: Andi Kleen <ak@linux.intel.com>
> Link: https://lore.kernel.org/all/20220818181530.2355034-1-kan.liang@linux.intel.com
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> 
> Lightly tested as I don't have hybrid hardware.  For the record, I'm not
> against supporting hybrid vPMUs in KVM, but it needs to be a dedicated
> effort and not implicitly rely on userspace to do the right thing (or get
> lucky).
> 
>  arch/x86/events/core.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 85a63a41c471..a67667c41cc8 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2974,17 +2974,18 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
>  
>  void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap)
>  {
> -	if (!x86_pmu_initialized()) {
> +	/*
> +	 * Hybrid PMUs don't play nice with virtualization unless userspace
> +	 * pins vCPUs _and_ can enumerate accurate information to the guest.
> +	 * Disable vPMU support for hybrid PMUs until KVM gains a way to let
> +	 * userspace opt into the dangers of hybrid vPMUs.
> +	 */
> +	if (!x86_pmu_initialized() || is_hybrid()) {
>  		memset(cap, 0, sizeof(*cap));
>  		return;
>  	}
>  
>  	cap->version		= x86_pmu.version;
> -	/*
> -	 * KVM doesn't support the hybrid PMU yet.
> -	 * Return the common value in global x86_pmu,
> -	 * which available for all cores.
> -	 */
>  	cap->num_counters_gp	= x86_pmu.num_counters;
>  	cap->num_counters_fixed	= x86_pmu.num_counters_fixed;
>  	cap->bit_width_gp	= x86_pmu.cntval_bits;
> 
> base-commit: de60733246ff4545a0483140c1f21426b8d7cb7f