From: "Vaden, Tom (HPE Server OS Architecture)" <tom.vaden@hpe.com>
To: Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Kan Liang <kan.liang@intel.com>, Jiri Olsa <jolsa@kernel.org>,
David Carrillo-Cisneros <davidcc@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Juergen Gross <jgross@suse.com>,
Alok Kataria <akataria@vmware.com>
Subject: Re: [RFC] perf/x86/intel: Disable check_msr for real hw
Date: Sun, 23 Jun 2019 23:44:55 +0000 [thread overview]
Message-ID: <73ec1d24-2dcf-1d48-2907-735fc1a4a7d0@hpe.com> (raw)
In-Reply-To: <20190623224031.GB5471@krava>
On 6/23/19 6:40 PM, Jiri Olsa wrote:
> On Fri, Jun 21, 2019 at 10:48:25AM -0700, Andi Kleen wrote:
>> On Fri, Jun 14, 2019 at 01:28:53PM +0200, Jiri Olsa wrote:
>>> hi,
>>> the HPE server can do POST tracing and have enabled LBR
>>> tracing during the boot, which makes check_msr fail falsly.
>>>
>>> It looks like check_msr code was added only to check on guests
>>> MSR access, would it be then ok to disable check_msr for real
>>> hardware? (as in patch below)
>>>
>>> We could also check if LBR tracing is enabled and make
>>> appropriate checks, but this change is simpler ;-)
>>>
>>> ideas? thanks,
>>> jirka
>>
>> Sorry for the late comment. I see this patch has been merged now.
>>
>> Unfortunately I don't think it's a good idea. The problem
>> is that the hypervisor flags are only set for a few hypervisors
>> that Linux knows about. But in practice there are many more
>> Hypervisors around that will not cause these flags to be set.
>> But these are still likely to miss MSRs.
>>
>> The other hypervisors are relatively obscure, but eventually
>> someone will hit problems.
>
> any idea if there's any other flag/way we could use to detect those?
>
> adding few virtualization folks to the loop
> and attaching the original patch
>
> thanks,
> jirka
>
Would it be reasonable to change the sense of the original patch in
commit 4550931 to only enable the check for the set of "certain hardware
emulators" and leave the check otherwise disabled by default? I'm
assuming that set is known (and small)?
>
> ---
> Tom Vaden reported false failure of check_msr function, because
> some servers can do POST tracing and enable LBR tracing during
> the boot.
>
> Kan confirmed that check_msr patch was to fix a bug report in
> guest, so it's ok to disable it for real HW.
>
> Cc: Kan Liang <kan.liang@intel.com>
> Reported-by: Tom Vaden <tom.vaden@hpe.com>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> arch/x86/events/intel/core.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 71001f005bfe..1194ae7e1992 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -20,6 +20,7 @@
> #include <asm/intel-family.h>
> #include <asm/apic.h>
> #include <asm/cpu_device_id.h>
> +#include <asm/hypervisor.h>
>
> #include "../perf_event.h"
>
> @@ -4050,6 +4051,13 @@ static bool check_msr(unsigned long msr, u64 mask)
> {
> u64 val_old, val_new, val_tmp;
>
> + /*
> + * Disable the check for real HW, so we don't
> + * mess up with potentionaly enabled regs.
> + */
> + if (hypervisor_is_type(X86_HYPER_NATIVE))
> + return true;
> +
> /*
> * Read the current value, change it and read it back to see if it
> * matches, this is needed to detect certain hardware emulators
>
next prev parent reply other threads:[~2019-06-24 2:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 11:28 Jiri Olsa
2019-06-14 13:33 ` Peter Zijlstra
2019-06-14 13:45 ` Liang, Kan
2019-06-16 14:13 ` [PATCH] " Jiri Olsa
2019-06-16 20:56 ` Vaden, Tom (HPE Server OS Architecture)
2019-06-17 14:41 ` [tip:perf/core] perf/x86/intel: Disable check_msr for real HW tip-bot for Jiri Olsa
2019-06-21 17:48 ` [RFC] perf/x86/intel: Disable check_msr for real hw Andi Kleen
2019-06-23 22:40 ` Jiri Olsa
2019-06-23 23:44 ` Vaden, Tom (HPE Server OS Architecture) [this message]
2019-06-24 8:06 ` Paolo Bonzini
2019-06-24 16:46 ` Andi Kleen
2019-06-24 18:06 ` Jiri Olsa
2019-06-24 18:38 ` Andi Kleen
2019-06-24 18:49 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73ec1d24-2dcf-1d48-2907-735fc1a4a7d0@hpe.com \
--to=tom.vaden@hpe.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=akataria@vmware.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=davidcc@google.com \
--cc=jgross@suse.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®