Android and compatibility with deprecated armv7 instructions

[ccross@google.com (Colin Cross)]

On Wed, Jul 2, 2014 at 3:01 AM, Will Deacon <will.deacon@arm.com> wrote:
>
> On Wed, Jul 02, 2014 at 12:48:00AM +0100, Mark Brown wrote:
> > On Tue, Jul 01, 2014 at 04:42:01PM -0700, Olof Johansson wrote:
> > > On Tue, Jul 1, 2014 at 4:06 PM, Colin Cross <ccross@google.com> wrote:
> > > > Would you consider taking support for SWP emulation, enabling CP15
> > > > barriers (CP15BEN bit only until there's a real device that needs
> > > > emulation, also requires clearing COMPAT_PSR_E_BIT in
> > > > compat_setup_return) and enabling SETEND, all behind a default-off
> > > > CONFIG_DEPRECATED_ARMV7_COMPAT?
> >
> > > It sounds really silly to push back against this, since it's actually
> > > needed by so many platforms out there.
>
> The big problem with emulating instructions that don't even appear in the
> hardware anymore is that we end up creating baggage which we can *never*
> remove.
>
> I'm against SWP emulation in the kernel for a number of reasons:
>
>   (1) The hardware doesn't have the instruction at all. If we start
>       emulating it, then we'll always have to emulate it and it doesn't
>       encourage software migration.
>
>   (2) I'm not convinced that it can't be handled in userspace by trapping
>       the SIGILL and emulating there (admittedly, this sounds difficult).
>
>   (3) The usual uses of SWP are in homebrew locking implementations and
>       are almost certainly a _bug_. For those v7 CPUs that could do SWP,
>       it's not even guaranteed to be atomic iirc. Trapping and emulating
>       is also bad for performance (although I note that Colin made an
>       argument that it was acceptable).
>
>   (4) This only affects legacy binaries. Should we also try to support OABI?
>       How about misaligned ldm/stm? We have to draw the line somewhere.

The problem is that we (Android) have to draw the line somewhere else
- there are too many highly visible apps in the app store that still
use these instructions.  When we add them back to our kernels, then we
are no longer ABI compatible with an upstream kernel.

> The CP15 barriers are a more interesting case, as the CPUs can *currently*
> support those if we flip a bit in the SCTLR. However, I see that as a
> slippery slope to emulation if CPUs stop supporting those instructions in
> the future (they almost certainly will).

I agree that this will likely lead to emulation when a CPU
manufacturer eventually decides to leave out hardware support,
although hopefully they won't if they see that the bit is set in SCTLR
on all Android devices.

> Whilst I appreciate that people are being bitten by this lack of emulation
> support, the vast majority of AArch32 code out there is working fine with
> the existing compat layer. I think the right way to solve this problem is
> to fix the code making use of the missing instructions.

A not-insignificant number of apps use these instructions - these
issues have been found by people taking the top 100 or so Android
apps, trying them out, and finding they crash.  Asking them all to
recompile is not feasible.  I view this issue as similar to Linus'
view on kernel ABIs - if somebody uses it, you have to keep it.  As
far as I know, nobody is generating new code with SWP and CP15 barrier
instructions, although ffmpeg is probably still using SETEND.