On Monday 26 Oct 2020 at 09:51:09 (+0000), Marc Zyngier wrote: > The hyp-init code starts by stashing a register in TPIDR_EL2 > in in order to free a register. This happens no matter if the > HVC call is legal or not. > > Although nothing wrong seems to come out of it, it feels odd > to alter the EL2 state for something that eventually returns > an error. > > Instead, use the fact that we know exactly which bits of the > __kvm_hyp_init call are non-zero to perform the check with > a series of EOR/ROR instructions, combined with a build-time > check that the value is the one we expect. Alternatively, could we make __kvm_hyp_init non-SMCCC compliant? While I understand how it makes sense to be compliant for 'proper' HVCs, this one really is an odd one that only makes sense on a very transient state. That would let us define our convention, and we can just say x0-x18 can be clobbered like any function call, which eradicates the issue Andrew tried to avoid with this tpidr_el2 trick. Thoughts? Thanks, Quentin
