Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   James Clark <james.clark@arm.com>
To:     coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
        kvmarm@lists.linux.dev, broonie@kernel.org
Cc:     maz@kernel.org, James Clark <james.clark@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>,
        Leo Yan <leo.yan@linaro.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        James Morse <james.morse@arm.com>,
        Kristina Martsenko <kristina.martsenko@arm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Rob Herring <robh@kernel.org>,
        Jintack Lim <jintack.lim@linaro.org>,
        Joey Gouly <joey.gouly@arm.com>, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] coresight: Allow guests to be traced when FEAT_TRF and VHE are present
Date:   Tue,  5 Sep 2023 11:21:13 +0100
Message-Id: <20230905102117.2011094-1-james.clark@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

FEAT_TRF is a Coresight feature that allows trace capture to be
completely filtered at different exception levels, unlike the existing
TRCVICTLR controls which may still emit target addresses of branches,
even if the following trace is filtered.

Without FEAT_TRF, it was possible to start a trace session on a host and
also collect trace from the guest as TRCVICTLR was never programmed to
exclude guests (and it could still emit target addresses even if it
was). Now when FEAT_TRF is present, because we don't write to
TRFCR_EL1, guest trace will be completely disabled.

This change fixes this issue, and also adds the ability to control it
with the Perf exclude_host and exclude_guest flags.

The first commit moves the register to sysreg because I add the EL12
version in the second commit.

The test results have some single spurious EL2 addresses, but I don't
think this is an issue with this patchset because it happens in the
host-userspace case which maintains the existing programming of
TRFCR. It's likely an issue with the model but I will follow it up
separately.

The corresponding change for nVHE is here [1]. The nVHE behaviour is
is reversed, currently guest trace is always generated because the host
already writes to TRFCR_EL1. This is the same both with and without
FEAT_TRF.

[1]: https://lore.kernel.org/kvmarm/20230804101317.460697-1-james.clark@arm.com/

---

Changes since v2:

 * E0TRE -> E0HTRE in TRFCR_EL2 to match Arm ARM
 * Add missing USE_TRFCR_EL1_TS enum value

Changes since v1:

 * Split new sysreg definitions into TRFCR_EL2 and TRFCR_ELx so that
   TRFCR_ELx doesn't include CX which TRFCR_EL1 doesn't have.
 * Mask out TS and CX before writing to TRFCR_EL1 because it doesn't
   have CX and TS has no effect.
 * Expand cover letter

James Clark (2):
  arm64/sysreg: Move TRFCR definitions to sysreg
  coresight: Allow guests to be traced when FEAT_TRF and VHE are present

 arch/arm64/include/asm/sysreg.h               | 12 -----
 arch/arm64/tools/sysreg                       | 41 +++++++++++++++
 .../coresight/coresight-etm4x-core.c          | 51 ++++++++++++++++---
 drivers/hwtracing/coresight/coresight-etm4x.h |  2 +-
 drivers/hwtracing/coresight/coresight-priv.h  |  3 ++
 5 files changed, 90 insertions(+), 19 deletions(-)

-- 
2.34.1