From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753890AbdBNNYb (ORCPT ); Tue, 14 Feb 2017 08:24:31 -0500 Received: from mga11.intel.com ([192.55.52.93]:14307 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753181AbdBNNYZ (ORCPT ); Tue, 14 Feb 2017 08:24:25 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,161,1484035200"; d="scan'208";a="1107238550" From: Alexander Shishkin To: Peter Zijlstra , Ingo Molnar Cc: linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, Arnaldo Carvalho de Melo , Borislav Petkov , Thomas Gleixner , Alexander Shishkin Subject: [PATCH 0/2] perf/x86/intel/pt: VMX related updates Date: Tue, 14 Feb 2017 15:24:14 +0200 Message-Id: <20170214132416.26400-1-alexander.shishkin@linux.intel.com> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On systems where PT does not coexist with VMX operation, we silently stop scheduling in PT events while VMX is on. It is confusing to the user as what they get in return is a perf session with no PT trace. So I added a check for any preexisting VMX users to the event creation path, so that we can tell the user right off the bat that it's not going to work (2/2). Also, when we do end up with PT events and VMX coexisting, the scheduling needs to be aware of it (1/2). Alexander Shishkin (2): perf/x86/intel/pt: Fail event scheduling on conflict with VMX perf/x86/intel/pt: Fail event creation if VMX operation is on arch/x86/events/intel/pt.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 2.11.0