[PATCH v1 2/2] arm64: smccc: Support SMCCC v1.3 SVE register saving hint

[Mark Brown]

On Tue, May 18, 2021 at 11:53:50AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > +alternative_if ARM64_SVE
> > +
> > +	adrp	x15, smccc_has_sve_hint

> The adrp instruction will give you a 4kB aligned address, which
> results in 1 chance out of 512 to point to the right location. The
> adr_l macro is probably what you want.

Ouch, yes.  This was working surprisingly well in my testing.

> >  		register unsigned long r2 asm("r2");			\
> >  		register unsigned long r3 asm("r3"); 			\
> >  		__declare_args(__count_args(__VA_ARGS__), __VA_ARGS__);	\
> > -		asm volatile(inst "\n" :				\
> > +		asm volatile(SMCCC_SVE_CHECK				\

> What happens when this is called from a context where
> __smccc_sve_check isn't mapped, nor does "current" mean anything? See
> arch/arm64/kvm/hyp/nvhe/psci-relay.c for an example.

Ah, oh dear.  I have to admit I haven't entirely been able to follow the
contexts the various bits of KVM run in yet, nor how much of the normal
kernel environment is being maintained :/ .  I do see some ifdefery with
__KVM_NVHE_HYPERVISOR__ elsewhere which could be used to take care of
that particular case either by providing a __hyp mapping or just not
trying to set the flag there (the latter seems safer) but I'm guessing
there's others.  Do we have a reliable way of identifying such contexts?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210518/d6b8b1ec/attachment.sig>