Mark,
I'd really appreciate it if you could send these as a series, instead of
an isolated patch every other day.
On 2020-02-18 12:44, Mark Brown wrote:
We have recently introduced new macros for annotating assembly symbols
for things that aren't C functions, SYM_CODE_START() and
SYM_CODE_END(),
in an effort to clarify and simplify our annotations of assembly files.
Using these for __bp_harden_hyp_vecs is more involved than for most
symbols
as this symbol is annotated quite unusually as rather than just have
the
explicit symbol we define _start and _end symbols which we then use to
compute the length. This does not play at all nicely with the new style
macros. Since the size of the vectors is a known constant which won't
vary
the simplest thing to do is simply to drop the separate _start and _end
symbols and just use a #define for the size.
Ideally we would have a build time assert to make sure we got this
right
but we don't have such a thing for assembly code and given how unlikely
the size is to change it seems disproportionately difficult to write
one
just for this.
Actually, we do have a pretty easy way to ensure this, see below.
[...]
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S
b/arch/arm64/kvm/hyp/hyp-entry.S
index 0aea8f9ab23d..8976276685a1 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -312,11 +312,11 @@ alternative_cb_end
.endm
.align 11
-ENTRY(__bp_harden_hyp_vecs_start)
+SYM_CODE_START(__bp_harden_hyp_vecs)
.rept BP_HARDEN_EL2_SLOTS
generate_vectors
.endr
1: .org __bp_harden_hyp_vecs + __BP_HARDEN_HYP_VECS_SZ
.org 1b
If you got it wrong one way or another, the assembler will scream
about the origin going backward. See eb7c11ee3c5 for details.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
