Android and compatibility with deprecated armv7 instructions

[Catalin Marinas]

On Sun, Jul 06, 2014 at 04:39:21PM +0100, Arnd Bergmann wrote:
> On Saturday 05 July 2014, Catalin Marinas wrote:
> > On 5 Jul 2014, at 19:43, Arnd Bergmann <arnd at arndb.de> wrote:
> >
> > > I think if a there is no way to turn off a feature, we can't really
> > > treat it as "deprecated", since we are lacking the most important tool
> > > to help users migrate away from it. Do you know why the architecture
> > > folks believe it makes sense to have distinct steps 1 and 2?
> > 
> > During this phase you usually only get compiler warnings which are
> > clearly not enough for already built apps.
> > 
> > But it looks like this is changing with ARMv8. SETEND is deprecated and
> > disable bit available. IT instruction also deprecated with a disable bit
> > (basically only allowing for one subsequent conditional instruction,
> > though I don’t think we can easily get rid of this one in user space).
> 
> Ok. I can also see ways to emulate SETEND from kernel side by modifying
> the user pt_regs, but I don't see how we could emulate IT without anything
> short of a full interpretation of user instructions from the kernel.

Single-step ;).

I need to get clarification but hopefully even if IT undefs, the SPSR IT
bits are still taken into account. So the emulation/warning handler
needs to decode IT and set SPSR in pt_regs accordingly before returning
to the next instruction.

But I agree, we can't remove this instruction entirely from the
architecture until we are completely sure there are no users (which is
nearly impossible).

> > > Another problem that I see with the way that features are phased out
> > > on ARM is how the hypervisor architecture makes it really hard to
> > > run a guest in an older architecture version. For instance on s390,
> > > you can basically emulate any prior machine from the past 50 years
> > > by selectively trapping some of the instructions from the guest
> > > into the hypervisor, at least for any instruction that has had
> > > a different behavior in the past.
> > 
> > That’s indeed not possible (basically a SWP at EL1 would trap as undef
> > at EL1 rather than EL2). But is there much value in this? Do we have a
> > large base of pre-built OS kernels? We are trying hard to get to single
> > Image, let alone using old builds of a kernel.
> 
> There are countless reasons why you'd want this actually, including:
> 
> - running an old arm7tdmi rtos build that you lost the source code for
>   but that would be cheaper to run on a new cortex-a7 emulating the
>   peripherals than to rewrite and revalidate

That's a too rare case to justify the additional CPU gates.

> - running OABI binaries in a 32-bit guest on an armv8 (or future version)

But you can already run an ARMv7 kernel now with OABI enabled on an
ARMv8 (either native or guest).

> - testing armv4 kernel builds in a kvm guest using qemu models

Again, this would require pre-ARMv6 MMU to be carried over for little
benefit (well, just to developers but hard to justify ARMv4 hardware
compatibility to marketing).

> - running Windows CE binaries in a virtual machine

It could be but a certain company never mentioned it.

> - running an ARMv8 SBSA based OS on ARMv9 hardware

I think back to ARMv7 we kind of have compatibility. What's missing is
some obsolete/undefined instructions to be trapped at EL2. This could
probably be considered if ARM decides to deprecated new instructions in
the future (though I think the current non-deprecated features are
stable enough).

-- 
Catalin