[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YwOk991q0iBgcQWC@worktop.programming.kicks-ass.net>
Date: Mon, 22 Aug 2022 17:47:03 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: "Liang, Kan" <kan.liang@...ux.intel.com>, acme@...hat.com,
linux-kernel@...r.kernel.org, alexander.shishkin@...ux.intel.com,
Jianfeng Gao <jianfeng.gao@...el.com>,
Andrew Cooper <Andrew.Cooper3@...rix.com>
Subject: Re: [RESEND PATCH] perf/x86/intel: Fix unchecked MSR access error
for Alder Lake N
On Mon, Aug 22, 2022 at 05:08:55PM +0200, Andi Kleen wrote:
>
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index 2db93498ff71..232e24324fd7 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -4473,6 +4473,11 @@ static bool init_hybrid_pmu(int cpu)
> > struct x86_hybrid_pmu *pmu = NULL;
> > int i;
> > + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
> > + pr_warn_once("hybrid PMU and virt are incompatible\n");
> > + return false;
> > + }
>
> It's totally possible to virtualize hybrid correctly, so I don't think this
> is justified
With a magic incantation and a sacrificial chicken sure, but the typical
guest will not have it set up right and we'll get the kernel doing
*splat*.
So I'm going to keep this and then some virt person can provide us a new
flag for when they think the hypervisor did the right thing and exclude
themselves from this ban.
Powered by blists - more mailing lists