Hi Andrew, On Thu, 03 Sep 2020 14:52:53 +0100, Andrew Scull <ascull@xxxxxxxxxx> wrote: > > nVHE symbols are prefixed but this is sometimes hidden from the host by > aliasing the non-prefixed symbol to the prefixed version with a macro. > This runs into problems if nVHE tries to use the symbol as it becomes > doubly prefixed. Avoid this by omitting the aliasing macro for nVHE. > > Cc: David Brazdil <dbrazdil@xxxxxxxxxx> > Signed-off-by: Andrew Scull <ascull@xxxxxxxxxx> > --- > arch/arm64/include/asm/kvm_asm.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h > index 6f98fbd0ac81..6f9c4162a764 100644 > --- a/arch/arm64/include/asm/kvm_asm.h > +++ b/arch/arm64/include/asm/kvm_asm.h > @@ -99,8 +99,11 @@ struct kvm_s2_mmu; > > DECLARE_KVM_NVHE_SYM(__kvm_hyp_init); > DECLARE_KVM_HYP_SYM(__kvm_hyp_vector); > + > +#ifndef __KVM_NVHE_HYPERVISOR__ > #define __kvm_hyp_init CHOOSE_NVHE_SYM(__kvm_hyp_init) > #define __kvm_hyp_vector CHOOSE_HYP_SYM(__kvm_hyp_vector) > +#endif Hmmm. Why do we limit this to these two symbols instead of making it a property of the "CHOOSE_*" implementation? The use of CHOOSE_HYP_SYM is already forbidden in the EL2 code (see how any symbol results in __nvhe_undefined_symbol being emitted). Does anything break if we have: #define CHOOSE_NVHE_SYM(x) x when __KVM_NVHE_HYPERVISOR__ is defined? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
