Subject: ARM64: Disabling warnings about deprecated armv8 instructions

From: [email-masked] (Michael Zoran)
Date: Mon, 30 Jan 2017 09:41:32 -0800

On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
> On 30 January 2017 at 16:58, Russell King - ARM Linux
> <[email-masked]> wrote:
> > On Mon, Jan 30, 2017 at 02:50:23PM +0000, Ard Biesheuvel wrote:
> 
> [..]
> > > I see. I was indeed mainly referring to userspace, which is what
> > > this
> > > thread is about, specifically setend and the CP15 barrier
> > > instructions. You can disagree with ARM's policy to deprecate and
> > > remove some instructions, but given the reality of it, I think it
> > > is
> > > perfectly reasonable to warn by default about setend instructions
> > > issued in 32-bit userspace when running under the 64-bit ARMv8
> > > kernel.
> > 
> > Linus has commented on this in the past, and his reaction (iirc)
> > was
> > that deprecating instructions that userspace uses is not a sane
> > behaviour, pointing out that instructions that i386 supported still
> > work today on the latest Intel CPUs.
> > 
> > He has a point, it's the same argument against breaking userspace
> > through making a change to the kernel.??It gives users a painful
> > experience.
> > 
> > That said, no one expects that you can run an i386 binary on ARM,
> > which is pretty much understood by users.??However, ARM vs ARM64
> > where ARM64 provides a 32-bit ARM compatible environment is a
> > totally different story - it's _not_ compatible if it complains
> > about instructions that _were_ legal with 32-bit ARM binaries.
> > It makes me question the value of providing what is an incompatible
> > environment to run older binaries.
> > 
> > The purpose of such an environment is to provide _compatibility_ to
> > older binaries.??You aren't providing a compatible environment if
> > you then decide to noisily warn about deprecated instructions.
> > 
> > You might as well just rebuild the binaries for a 64-bit
> > environment
> > and stop the illusion of a 32-bit compatible environment, because
> > it
> > isn't.
> > 
> 
> Well, the question is really how to deal with 32-bit compatibility
> given the fact that the ARM architecture will drop such instructions
> in its next revision. Whether we agree with that, and whether we
> should argue our positions with the architects if we don't is not
> relevant here.
> 
> What is relevant is whether we inform userspace if we spot such a
> deprecated instruction, and I think we should.
> 
> Note that this is not only an issue for the arm64 kernel. The 32-bit
> kernel will have the exact same issue when you try to run it on
> hardware that no longer has support for those instructions.

Just to inject two cents worth since I'm still on the thread and I
originally started the topic...

The Intel comparison seems relevant.  I think in theory you can still
run old MS-DOS software on an Intel PC if you were so inclined to do
so.

I would think the best would be to turn the warnings off by default
when running in 32 bit mode with the option to turn them back on.  Then
as time progresses more of more of these instructions can be converted
to software emulation and removed from the hardware.  And hopefully as
time progresses, all the user mode software gets upgraded to 64 bit so
that 32 bit get dropped.

The issue seems to me to be more that the kernel is screaming in the
logs rather then if it's emulating the instructions in hardware or
software.