Android and compatibility with deprecated armv7 instructions

[Colin Cross]

On Mon, Jul 7, 2014 at 5:28 AM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Sat, 5 Jul 2014 12:14:07 +0100, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Jul 04, 2014 at 02:22:50PM +0100, Grant Likely wrote:
>> > On Thu, 3 Jul 2014 18:43:18 +0100, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > > On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
>> > > > So, no. I completely reject any notion that breaking existing apps is
>> > > > okay. If we're going to say that v8 still supports 32-bit apps, then
>> > > > it has to be all of v7, not just the 'good' bits. Nor do I think
>> > > > saying "it's just a bunch of games" justifies anything. We're kernel
>> > > > engineers. Applications are applications and we don't break userspace.
>> > > > Period.
>> > >
>> > > Here you need to define user-space. OABI?
>> >
>> > This is where we can be pragmatic. Listen to our users. Colin was very
>> > clear about what some apps need in order to keep working. He's not even
>> > asking for old kernels or system libraries to be supported because he
>> > has control over those components and they can be fixed. The important
>> > ABI is the ABI used by Android applications.
>> >
>> > We can drop ABIs that nobody uses. If nobody complains, is it really
>> > broken?
>>
>> OK, so I think we now agree that being asked not to break the ABI ever
>> is not feasible (and not in the community's interest either; think about
>> carrying over NWFPE for ARMv8 just because someone wants to run an old
>> distro when there are alternatives already, such requests would need
>> proper justification).
>>
>> Another aspect is that users don't always know what's good (or bad) for
>> them. EABI provided means via kuser helpers to use arch-independent
>> barrier code and cmpxchg. Glibc and various threads libraries moved to
>> using them but as we can see, not all user space. As Russell pointed
>> out, we failed to raise the SWP issue properly in the ARMv7 kernel (more
>> warnings, always emulation) and I see this as a valid reason to allow
>> for a _transition_ period in ARMv8.
>>
>> But we have to agree on a way to handle deprecated/removed architecture
>> features (as I said, some of them are removed for good reasons). And
>> that's also for user's benefit, performance wise they should rather use
>> native than emulated features.
>>
>> The timeline I propose would be:
>>
>> 1. Architecture feature deprecation (still present, no way to disable)
>>    - In Linux we need to find ways and push for alternatives to be
>>      adopted by user space (like we did with kuser helpers)
>> 2. Architecture feature disabling (still present but needs to be enabled
>>    explicitly via SCTLR bit)
>>    - Linux disables the feature by default and provides emulation
>>      (enabled by default), clear warnings
>>    - In certain cases, there may be justification to enable the hardware
>>      feature but certainly not in defconfig nor distro Image builds.
>>      Otherwise they can't complain that users are still using such
>>      feature at point 3 below
>> 3. Architecture feature removed
>>    - Default Linux behaviour changes to SIGILL
>>    - Emulation could be still available in the kernel but maybe under
>>      a CONFIG_EXPERT option
>> 4. Eventually remove kernel emulation support entirely (or don't carry
>>    it over to a new port, though I don't foresee any arm128 ;))
>>
>> With SWP, we are currently at 3/4 with the counter arguments that 2
>> wasn't entirely clear to users, so the transition needs to be
>> carried over for ARMv8 (but I'm against 2 for arm64, 3 is as far as I
>> would go). Arguably, with CP15 barriers we are at point 2, in which case
>> if we add them to the arm64 kernel, they should be emulated with clear
>> warnings (ratelimited).
>
> I could quibble on details, but I'm fine with that approach.
>
> It would also be good to have ongoing feedback about if the emulation is
> getting used in the field. Colin, if the kernel emits warnings on
> emulation, is that something that Google gathers statistics on for
> devices in the field?

We do capture snapshots of the kernel log on dogfooding and
experimental devices, but it's not a great source for statistical data
because it only gets the most recent 64kB.  We do capture per-process
cpu stats, if we could get it into a
/proc/<pid>/deprecated_instructions file that would provide the most
accurate statistics.  I can also talk to our developer relations teams
about approaching it from the Play Store side.