On Tue, 30 Mar 2021 16:23:14 +0100, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:
On 26/03/2021 16:55, Mathieu Poirier wrote:
On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:
For a nvhe host, the EL2 must allow the EL1&0 translation regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must be saved/restored over a trip to the guest. Also, before entering the guest, we must flush any trace data if the TRBE was enabled. And we must prohibit the generation of trace while we are in EL1 by clearing the TRFCR_EL1.
For vhe, the EL2 must prevent the EL1 access to the Trace Buffer.
Cc: Will Deacon will@kernel.org Cc: Catalin Marinas catalin.marinas@arm.com Cc: Marc Zyngier maz@kernel.org Cc: Mark Rutland mark.rutland@arm.com Cc: Anshuman Khandual anshuman.khandual@arm.com Acked-by: Mathieu Poirier mathieu.poirier@linaro.org Signed-off-by: Suzuki K Poulose suzuki.poulose@arm.com
arch/arm64/include/asm/el2_setup.h | 13 +++++++++ arch/arm64/include/asm/kvm_arm.h | 2 ++ arch/arm64/include/asm/kvm_host.h | 2 ++ arch/arm64/kernel/hyp-stub.S | 3 ++- arch/arm64/kvm/debug.c | 6 ++--- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 42 ++++++++++++++++++++++++++++++ arch/arm64/kvm/hyp/nvhe/switch.c | 1 + 7 files changed, 65 insertions(+), 4 deletions(-)
Marc - do you want me to pick up this one?
I think the kvmarm tree is the best route for this patch, given the amount of changes the tree is going through, in the areas this patch touches. Or else there would be conflicts with merging. And this patch depends on the patches from this series that were queued.
Here is the depency tree :
a) kvm-arm fixes for debug (Patch 1, 2) & SPE save-restore fix (queued in v5.12-rc3)
b) TRBE defintions and Trace synchronization barrier (Patches 5 & 6)
c) kvm-arm TRBE host support (Patch 7)
d) TRBE driver support (and the ETE changes)
(c) code merge depends on -> (a) + (b) (d) build (no conflicts) depends on -> (b)
Now (d) has an indirect dependency on (c) for operational correctness at runtime. So, if :
kvmarm tree picks up : b + c coresight tree picksup : b + d
and if we could ensure the merge order of the trees are in kvmarm greg-kh (device-misc tree) (coresight goes via this tree)
Greg's char-misc tree is based on the rc releases rather than next. As such it is a while before other branches like kvmarm get merged, causing all sort of compilation breakage.
we should be fine.
Additionally, we could rip out the Kconfig changes from the TRBE patch and add it only at the rc1, once we verify both the trees are in to make sure the runtime operation dependency is not triggered.
We could also do that but Greg might frown at the tactic, and rightly so.
We do that all the times. Otherwise, it is hardly possible to build an infrastructure that spans across multiple subsystems *and* involves userspace. I really wouldn't worry about that.
M.