On 06/01/2025 2:48 pm, Marc Zyngier wrote:

On Mon, 06 Jan 2025 14:24:35 +0000, James Clark james.clark@linaro.org wrote:

...

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).

With FEAT_TRF, the current behavior of trace in guests exists depends on whether nVHE or VHE are being used. Both of the examples below are from the host's point of view, as Coresight isn't accessible from guests. This patchset is only relevant to when FEAT_TRF exists, otherwise there is no change.

Current behavior:

nVHE/pKVM:

Because the host and the guest are both using TRFCR_EL1, trace will be generated in guests depending on the same filter rules the host is using. For example if the host is tracing userspace only, then guest userspace trace will also be collected.

(This is further limited by whether TRBE is used because an issue with TRBE means that it's completely disabled in nVHE guests, but it's possible to have other tracing components.)

VHE:

With VHE, the host filters will be in TRFCR_EL2, but the filters in TRFCR_EL1 will be active when the guest is running. Because we don't write to TRFCR_EL1, guest trace will be completely disabled.

New behavior:

The guest filtering rules from the Perf session are now honored for both nVHE and VHE modes. This is done by either writing to TRFCR_EL12 at the start of the Perf session and doing nothing else further, or caching the guest value and writing it at guest switch for nVHE. In pKVM, trace is now be disabled for both protected and unprotected guests.

There is also an optimization where the Coresight drivers pass their enabled state to KVM. This means in the common case KVM doesn't have to touch any sysregs when the feature isn't in use.

Applies to kvmarm/next (00163be8bb59).

Can you *PLEASE* stop this absolutely nonsense of posting patches based on top of random commits? Please look at how we integrate new developments: they are *always* based on an early -rc tag (usually -rc3).

If you depend on other patches, add them to your series and post the whole thing.

Thanks,

M.

Sure, I re-posted it on the latest -rc with a few commits picked up.

Thanks James