From: catalin.marinas@arm•com (Catalin Marinas)
To: linux-arm-kernel@lists•infradead.org
Subject: Android and compatibility with deprecated armv7 instructions
Date: Mon, 7 Jul 2014 15:35:45 +0100 [thread overview]
Message-ID: <20140707143545.GD32276@arm.com> (raw)
In-Reply-To: <201407061739.22152.arnd@arndb.de>
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@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
next prev parent reply other threads:[~2014-07-07 14:35 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 23:06 Android and compatibility with deprecated armv7 instructions Colin Cross
2014-07-01 23:42 ` Olof Johansson
2014-07-01 23:48 ` Mark Brown
2014-07-02 10:01 ` Will Deacon
2014-07-02 15:48 ` Colin Cross
2014-07-02 16:16 ` Will Deacon
2014-07-02 18:03 ` Christopher Covington
2014-07-02 18:25 ` Will Deacon
2014-07-02 19:47 ` Mark Brown
2014-07-05 21:26 ` Rob Herring
2014-07-02 16:39 ` Mark Brown
2014-07-02 17:01 ` Will Deacon
2014-07-02 17:33 ` Mark Brown
2014-07-02 22:14 ` Grant Likely
2014-07-03 10:41 ` Catalin Marinas
2014-07-03 14:28 ` Arnd Bergmann
2014-07-03 15:00 ` Russell King - ARM Linux
2014-07-03 15:40 ` Grant Likely
2014-07-03 17:13 ` Catalin Marinas
2014-07-03 17:48 ` Russell King - ARM Linux
2014-07-03 18:15 ` Arnd Bergmann
2014-07-03 18:30 ` Russell King - ARM Linux
2014-07-03 18:37 ` Will Deacon
2014-07-03 18:52 ` Russell King - ARM Linux
2014-07-03 19:00 ` Will Deacon
2014-07-04 8:57 ` Catalin Marinas
2014-07-04 9:25 ` Russell King - ARM Linux
2014-07-04 10:12 ` Arnd Bergmann
2014-07-04 14:09 ` Dr. David Alan Gilbert
2014-07-04 12:56 ` Grant Likely
2014-07-04 13:31 ` Russell King - ARM Linux
2014-07-03 18:46 ` Will Deacon
2014-07-03 18:53 ` Arnd Bergmann
2014-07-03 19:07 ` Russell King - ARM Linux
2014-07-03 19:40 ` Arnd Bergmann
2014-07-04 13:25 ` Grant Likely
2014-07-03 16:22 ` Grant Likely
2014-07-03 17:05 ` Russell King - ARM Linux
2014-07-03 17:32 ` Will Deacon
2014-07-03 18:23 ` Arnd Bergmann
2014-07-03 18:38 ` Peter Maydell
2014-07-03 18:40 ` Will Deacon
2014-07-03 18:32 ` Mark Brown
2014-07-03 22:16 ` Måns Rullgård
2014-07-03 22:47 ` Russell King - ARM Linux
2014-07-04 7:08 ` Ard Biesheuvel
2014-07-04 8:24 ` Catalin Marinas
2014-07-04 8:33 ` Ard Biesheuvel
2014-07-04 9:21 ` Måns Rullgård
2014-07-04 9:34 ` Russell King - ARM Linux
2014-07-04 10:21 ` Måns Rullgård
2014-07-04 10:33 ` Russell King - ARM Linux
2014-07-04 11:00 ` Ard Biesheuvel
2014-07-04 17:28 ` Nicolas Pitre
2014-07-03 17:43 ` Catalin Marinas
2014-07-04 13:22 ` Grant Likely
2014-07-04 19:24 ` Mark Brown
2014-07-04 19:33 ` Arnd Bergmann
2014-07-04 22:06 ` Måns Rullgård
2014-07-04 22:08 ` Mark Brown
2014-07-05 11:14 ` Catalin Marinas
2014-07-05 11:25 ` Russell King - ARM Linux
2014-07-05 16:43 ` Mark Brown
2014-07-05 17:06 ` Catalin Marinas
2014-07-05 18:43 ` Arnd Bergmann
2014-07-05 21:19 ` Catalin Marinas
2014-07-06 15:39 ` Arnd Bergmann
2014-07-07 13:59 ` Janne Grunau
2014-07-07 14:52 ` Catalin Marinas
2014-07-07 17:52 ` Janne Grunau
2014-07-07 15:43 ` Peter Maydell
2014-07-08 5:28 ` Måns Rullgård
2014-07-07 14:35 ` Catalin Marinas [this message]
2014-07-07 21:26 ` Arnd Bergmann
2014-07-07 12:28 ` Grant Likely
2014-07-07 18:35 ` Colin Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140707143545.GD32276@arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox