On Tue, Mar 30, 2021 at 10:33:51AM -0600, Mathieu Poirier wrote:

On Tue, 30 Mar 2021 at 09:35, Greg KH [off-list ref] wrote:

quoted

On Tue, Mar 30, 2021 at 09:23:14AM -0600, Mathieu Poirier wrote:

quoted

On Tue, Mar 30, 2021 at 11:38:18AM +0100, Suzuki K Poulose wrote:

quoted

On 26/03/2021 16:55, Mathieu Poirier wrote:

quoted

On Tue, Mar 23, 2021 at 12:06:35PM +0000, Suzuki K Poulose wrote:

quoted

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

My tree can not be based on -next, and neither can any other
maintainer's tree, as next is composed of maintainer trees :)

Exactly

quoted

quoted

quoted

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.  The
usual way to work with complex merge dependencies is to proceed in steps, which
would mean that all KVM related patches go in the v5.13 merge window.  When that
is done we add the ETE/TRBE for the v5.14 merge window.  I agree that we waste
an entire cycle but it guarantees to avoid breaking builds and follows the
conventional way to do things.

Or someone creates a single branch with a signed tag and it gets pulled
into multiple maintainer's trees and never rebased.  We've done that
lots of time, nothing new there.  Or everything goes through one tree,
or you wait a release cycle.

You have 3 choices, pick one :)

I'm perfectly happy with getting this entire set merged via Marc's
kvmarm tree, as long as you are fine with it.

No objection from me at all for this to go that way.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel