From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Android and compatibility with deprecated armv7 instructions
Date: Sat, 05 Jul 2014 20:43:26 +0200 [thread overview]
Message-ID: <4473002.jGohFvPsvi@wuerfel> (raw)
In-Reply-To: <FFC4CCB1-115D-4A20-A79D-78200D02D90F@arm.com>
On Saturday 05 July 2014 18:06:29 Catalin Marinas wrote:
> On 5 Jul 2014, at 17:43, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Jul 05, 2014 at 12:14:07PM +0100, Catalin Marinas wrote:
> >
> >> 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)
> >
> > Is it worth adding a non-default option to either disable and emulate or
> > just completely disable during this phase rather than at step 2 (perhaps
> > with a sysctl)? That would help people who want to test that what they
> > are doing is going to work going forwards. The work is going to have to
> > happen anyway.
>
> The problem is that when the feature is deprecated, we may not always
> get the option to disable it (it?s more of an advance warning to think
> about it, that?s why I added emulation at step 2). For example SWP has
> been deprecated in ARMv6 but no way to disable it until ARMv7 MP. If we
> get the option (and we should probably recommend this to the
> architects), I agree, you can start the emulation work at step 1 but
> defaulting to native deprecated feature rather than emulation.
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?
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.
Arnd
next prev parent reply other threads:[~2014-07-05 18:43 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 [this message]
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
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=4473002.jGohFvPsvi@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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