ARM64: Disabling warnings about deprecated armv8 instructions

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

Hi,

I'm not sure if this if the correct place to be asking this.   The RPI
3 running ARM64 is slowly reaching the point of being about to
seriously run a 32 bit vender OS like Raspbian.  When running Raspbian,
I'm seeing a very large number(thousands) of kernel log messages about
deprecated instructions especially setend and barrier instuctions. 
This can be very annoying and is completely filling the kernel log.

I'm considering submitting a patch to add a Kconfig option to disable
these warnings with the default being to keep the warnings enabled.  I
was wondering if such a patch could be seriously considered.

I completely understand thee need for these warnings and the need to
encourage people to update software, but at the same time some software
like Raspbian needs to run on a large number of processors with a
simple install so updating isn't always realistic.  

Running a 64 bit kernel with a 32 bit userland is better from a upgrade
point of view then always running 32 just because they want to not have
the machine slowed by excessive logging.

Thanks.

ARM64: Disabling warnings about deprecated armv8 instructions

[Alexander Stein]

Hi Michael,

On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
> I'm not sure if this if the correct place to be asking this.   The RPI
> 3 running ARM64 is slowly reaching the point of being about to
> seriously run a 32 bit vender OS like Raspbian.  When running Raspbian,
> I'm seeing a very large number(thousands) of kernel log messages about
> deprecated instructions especially setend and barrier instuctions.
> This can be very annoying and is completely filling the kernel log.
> 
> I'm considering submitting a patch to add a Kconfig option to disable
> these warnings with the default being to keep the warnings enabled.  I
> was wondering if such a patch could be seriously considered.

Could you please provide an example of those warning an what is trigging 
those?

Thanks and best regards,
Alexander

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> Hi Michael,
> 
> On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
> > I'm not sure if this if the correct place to be asking this.???The
> > RPI
> > 3 running ARM64 is slowly reaching the point of being about to
> > seriously run a 32 bit vender OS like Raspbian.??When running
> > Raspbian,
> > I'm seeing a very large number(thousands) of kernel log messages
> > about
> > deprecated instructions especially setend and barrier instuctions.
> > This can be very annoying and is completely filling the kernel log.
> > 
> > I'm considering submitting a patch to add a Kconfig option to
> > disable
> > these warnings with the default being to keep the warnings
> > enabled.??I
> > was wondering if such a patch could be seriously considered.
> 
> Could you please provide an example of those warning an what is
> trigging?
> those?
> 
> Thanks and best regards,
> Alexander

Sure, here is a snipped from dmesg.  I think this is happening because
the entire Raspbian OS is compiled with a custom gcc compiler that is
targeting arm6+VFP.

I can double check, but I think the instructions are being emulated in 
hardware so they are just filling the log and slowing things down.

[10685.558480] cp15barrier_handler: 197896 callbacks suppressed
[10685.558487] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf707fe9c
[10685.558504] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7015944
[10685.558511] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7012494
[10685.558518] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf70159b4
[10685.558527] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7011478
[10685.558533] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf70114e8
[10685.558540] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7015944
[10685.558547] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7012494
[10685.558553] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf70159b4
[10685.558560] "Xorg" (656) uses deprecated CP15 Barrier instruction at
0xf7011478
[10685.559179] compat_setend_handler: 1078 callbacks suppressed
[10685.559188] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a66f4
[10685.559196] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a6bd8
[10685.559209] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a66f4
[10685.559216] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a6bd8
[10685.559231] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a66f4
[10685.559237] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a6bd8
[10685.559246] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a66f4
[10685.559253] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a6bd8
[10685.559269] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a66f4
[10685.559276] "systemd-journal" (138) uses deprecated setend
instruction at 0xf76a6bd8

ARM64: Disabling warnings about deprecated armv8 instructions

[Jisheng Zhang]

On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:

> On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > Hi Michael,
> > 
> > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:  
> > > I'm not sure if this if the correct place to be asking this.???The
> > > RPI
> > > 3 running ARM64 is slowly reaching the point of being about to
> > > seriously run a 32 bit vender OS like Raspbian.??When running
> > > Raspbian,
> > > I'm seeing a very large number(thousands) of kernel log messages
> > > about
> > > deprecated instructions especially setend and barrier instuctions.
> > > This can be very annoying and is completely filling the kernel log.
> > > 
> > > I'm considering submitting a patch to add a Kconfig option to
> > > disable
> > > these warnings with the default being to keep the warnings
> > > enabled.??I
> > > was wondering if such a patch could be seriously considered.  
> > 
> > Could you please provide an example of those warning an what is
> > trigging?
> > those?
> > 
> > Thanks and best regards,
> > Alexander  
> 
> Sure, here is a snipped from dmesg.  I think this is happening because
> the entire Raspbian OS is compiled with a custom gcc compiler that is
> targeting arm6+VFP.

IMHO, this is the root cause. I didn't see below warnings from dmesg with
armhf debian and ubuntu If the underlying HW is armv8 compatible, it
doesn't make sense to target the compiler to armv6

Thanks

> 
> I can double check, but I think the instructions are being emulated in 
> hardware so they are just filling the log and slowing things down.
> 
> [10685.558480] cp15barrier_handler: 197896 callbacks suppressed
> [10685.558487] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf707fe9c
> [10685.558504] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7015944
> [10685.558511] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7012494
> [10685.558518] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70159b4
> [10685.558527] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7011478
> [10685.558533] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70114e8
> [10685.558540] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7015944
> [10685.558547] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7012494
> [10685.558553] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70159b4
> [10685.558560] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7011478
> [10685.559179] compat_setend_handler: 1078 callbacks suppressed
> [10685.559188] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559196] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559209] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559216] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559231] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559237] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559246] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559253] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559269] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559276] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net> wrote:
> On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
>> Hi Michael,
>>
>> On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
>> > I'm not sure if this if the correct place to be asking this.   The
>> > RPI
>> > 3 running ARM64 is slowly reaching the point of being about to
>> > seriously run a 32 bit vender OS like Raspbian.  When running
>> > Raspbian,
>> > I'm seeing a very large number(thousands) of kernel log messages
>> > about
>> > deprecated instructions especially setend and barrier instuctions.
>> > This can be very annoying and is completely filling the kernel log.
>> >
>> > I'm considering submitting a patch to add a Kconfig option to
>> > disable
>> > these warnings with the default being to keep the warnings
>> > enabled.  I
>> > was wondering if such a patch could be seriously considered.
>>
>> Could you please provide an example of those warning an what is
>> trigging
>> those?
>>
>> Thanks and best regards,
>> Alexander
>
> Sure, here is a snipped from dmesg.  I think this is happening because
> the entire Raspbian OS is compiled with a custom gcc compiler that is
> targeting arm6+VFP.
>
> I can double check, but I think the instructions are being emulated in
> hardware so they are just filling the log and slowing things down.
>
> [10685.558480] cp15barrier_handler: 197896 callbacks suppressed
> [10685.558487] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf707fe9c
> [10685.558504] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7015944
> [10685.558511] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7012494
> [10685.558518] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70159b4
> [10685.558527] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7011478
> [10685.558533] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70114e8
> [10685.558540] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7015944
> [10685.558547] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7012494
> [10685.558553] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf70159b4
> [10685.558560] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> 0xf7011478
> [10685.559179] compat_setend_handler: 1078 callbacks suppressed
> [10685.559188] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559196] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559209] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559216] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559231] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559237] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559246] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559253] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
> [10685.559269] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a66f4
> [10685.559276] "systemd-journal" (138) uses deprecated setend
> instruction at 0xf76a6bd8
>

You can disable the emulation by doing

echo 2 >/proc/sys/abi/setend
echo 2 >/proc/sys/abi/cp15_barrier

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 09:09 +0000, Ard Biesheuvel wrote:
> On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net>
> wrote:
> > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > Hi Michael,
> > > 
> > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
> > > > I'm not sure if this if the correct place to be asking
> > > > this.???The
> > > > RPI
> > > > 3 running ARM64 is slowly reaching the point of being about to
> > > > seriously run a 32 bit vender OS like Raspbian.??When running
> > > > Raspbian,
> > > > I'm seeing a very large number(thousands) of kernel log
> > > > messages
> > > > about
> > > > deprecated instructions especially setend and barrier
> > > > instuctions.
> > > > This can be very annoying and is completely filling the kernel
> > > > log.
> > > > 
> > > > I'm considering submitting a patch to add a Kconfig option to
> > > > disable
> > > > these warnings with the default being to keep the warnings
> > > > enabled.??I
> > > > was wondering if such a patch could be seriously considered.
> > > 
> > > Could you please provide an example of those warning an what is
> > > trigging
> > > those?
> > > 
> > > Thanks and best regards,
> > > Alexander
> > 
> > Sure, here is a snipped from dmesg.??I think this is happening
> > because
> > the entire Raspbian OS is compiled with a custom gcc compiler that
> > is
> > targeting arm6+VFP.
> > 
> > I can double check, but I think the instructions are being emulated
> > in
> > hardware so they are just filling the log and slowing things down.
> > 
> 
> You can disable the emulation by doing
> 
> echo 2 >/proc/sys/abi/setend
> echo 2 >/proc/sys/abi/cp15_barrier

I don't want to disable the emulation since I want to run old binaries.
   I just want to disable the warning...

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 22 January 2017 at 09:33, Michael Zoran <mzoran@crowfest.net> wrote:
> On Sun, 2017-01-22 at 09:09 +0000, Ard Biesheuvel wrote:
>> On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net>
>> wrote:
>> > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
>> > > Hi Michael,
>> > >
>> > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
>> > > > I'm not sure if this if the correct place to be asking
>> > > > this.   The
>> > > > RPI
>> > > > 3 running ARM64 is slowly reaching the point of being about to
>> > > > seriously run a 32 bit vender OS like Raspbian.  When running
>> > > > Raspbian,
>> > > > I'm seeing a very large number(thousands) of kernel log
>> > > > messages
>> > > > about
>> > > > deprecated instructions especially setend and barrier
>> > > > instuctions.
>> > > > This can be very annoying and is completely filling the kernel
>> > > > log.
>> > > >
>> > > > I'm considering submitting a patch to add a Kconfig option to
>> > > > disable
>> > > > these warnings with the default being to keep the warnings
>> > > > enabled.  I
>> > > > was wondering if such a patch could be seriously considered.
>> > >
>> > > Could you please provide an example of those warning an what is
>> > > trigging
>> > > those?
>> > >
>> > > Thanks and best regards,
>> > > Alexander
>> >
>> > Sure, here is a snipped from dmesg.  I think this is happening
>> > because
>> > the entire Raspbian OS is compiled with a custom gcc compiler that
>> > is
>> > targeting arm6+VFP.
>> >
>> > I can double check, but I think the instructions are being emulated
>> > in
>> > hardware so they are just filling the log and slowing things down.
>> >
>>
>> You can disable the emulation by doing
>>
>> echo 2 >/proc/sys/abi/setend
>> echo 2 >/proc/sys/abi/cp15_barrier
>
> I don't want to disable the emulation since I want to run old binaries.
>    I just want to disable the warning...
>

That is exactly what this does: the A53 can execute these instructions
just fine, but due to the fact that they are deprecated by the
architecture, they are trapped and emulated by default.

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 17:05 +0800, Jisheng Zhang wrote:
> On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:
> 
> > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > Hi Michael,
> > > 
> > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
> > > wrote:??
> > > > I'm not sure if this if the correct place to be asking
> > > > this.???The
> > > > RPI
> > > > 3 running ARM64 is slowly reaching the point of being about to
> > > > seriously run a 32 bit vender OS like Raspbian.??When running
> > > > Raspbian,
> > > > I'm seeing a very large number(thousands) of kernel log
> > > > messages
> > > > about
> > > > deprecated instructions especially setend and barrier
> > > > instuctions.
> > > > This can be very annoying and is completely filling the kernel
> > > > log.
> > > > 
> > > > I'm considering submitting a patch to add a Kconfig option to
> > > > disable
> > > > these warnings with the default being to keep the warnings
> > > > enabled.??I
> > > > was wondering if such a patch could be seriously considered.??
> > > 
> > > Could you please provide an example of those warning an what is
> > > trigging?
> > > those?
> > > 
> > > Thanks and best regards,
> > > Alexander??
> > 
> > Sure, here is a snipped from dmesg.??I think this is happening
> > because
> > the entire Raspbian OS is compiled with a custom gcc compiler that
> > is
> > targeting arm6+VFP.
> 
> IMHO, this is the root cause. I didn't see below warnings from dmesg
> with
> armhf debian and ubuntu If the underlying HW is armv8 compatible, it
> doesn't make sense to target the compiler to armv6
> 
> 

Advanced users can install a different OS. Beginners can't and will
need a single OS image for simple install.

Does anybody know if these instructions are detected at runtime?  I'm
also looking into an issue with Mathmatica due to broken OS detection. 
It appears that arm64 is currently missing some of the CPU spoofing
that happens on other architectures...

 

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 22 January 2017 at 09:38, Michael Zoran <mzoran@crowfest.net> wrote:
> On Sun, 2017-01-22 at 17:05 +0800, Jisheng Zhang wrote:
>> On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:
>>
>> > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
>> > > Hi Michael,
>> > >
>> > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
>> > > wrote:
>> > > > I'm not sure if this if the correct place to be asking
>> > > > this.   The
>> > > > RPI
>> > > > 3 running ARM64 is slowly reaching the point of being about to
>> > > > seriously run a 32 bit vender OS like Raspbian.  When running
>> > > > Raspbian,
>> > > > I'm seeing a very large number(thousands) of kernel log
>> > > > messages
>> > > > about
>> > > > deprecated instructions especially setend and barrier
>> > > > instuctions.
>> > > > This can be very annoying and is completely filling the kernel
>> > > > log.
>> > > >
>> > > > I'm considering submitting a patch to add a Kconfig option to
>> > > > disable
>> > > > these warnings with the default being to keep the warnings
>> > > > enabled.  I
>> > > > was wondering if such a patch could be seriously considered.
>> > >
>> > > Could you please provide an example of those warning an what is
>> > > trigging
>> > > those?
>> > >
>> > > Thanks and best regards,
>> > > Alexander
>> >
>> > Sure, here is a snipped from dmesg.  I think this is happening
>> > because
>> > the entire Raspbian OS is compiled with a custom gcc compiler that
>> > is
>> > targeting arm6+VFP.
>>
>> IMHO, this is the root cause. I didn't see below warnings from dmesg
>> with
>> armhf debian and ubuntu If the underlying HW is armv8 compatible, it
>> doesn't make sense to target the compiler to armv6
>>
>>
>
> Advanced users can install a different OS. Beginners can't and will
> need a single OS image for simple install.
>

That single OS image can simply test for the presence of
/proc/sys/abi, and perform the writes if it is there.

> Does anybody know if these instructions are detected at runtime?

What do you mean by 'detected'?

> I'm
> also looking into an issue with Mathmatica due to broken OS detection.
> It appears that arm64 is currently missing some of the CPU spoofing
> that happens on other architectures...
>

Could you elaborate? What do you think should be there that isn't?

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 09:36 +0000, Ard Biesheuvel wrote:
> On 22 January 2017 at 09:33, Michael Zoran <mzoran@crowfest.net>
> wrote:
> > On Sun, 2017-01-22 at 09:09 +0000, Ard Biesheuvel wrote:
> > > On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net>
> > > wrote:
> > > > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > > > Hi Michael,
> > > > > 
> > > > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
> > > > > wrote:
> > > > > > I'm not sure if this if the correct place to be asking
> > > > > > this.???The
> > > > > > RPI
> > > > > > 3 running ARM64 is slowly reaching the point of being about
> > > > > > to
> > > > > > seriously run a 32 bit vender OS like Raspbian.??When
> > > > > > running
> > > > > > Raspbian,
> > > > > > I'm seeing a very large number(thousands) of kernel log
> > > > > > messages
> > > > > > about
> > > > > > deprecated instructions especially setend and barrier
> > > > > > instuctions.
> > > > > > This can be very annoying and is completely filling the
> > > > > > kernel
> > > > > > log.
> > > > > > 
> > > > > > I'm considering submitting a patch to add a Kconfig option
> > > > > > to
> > > > > > disable
> > > > > > these warnings with the default being to keep the warnings
> > > > > > enabled.??I
> > > > > > was wondering if such a patch could be seriously
> > > > > > considered.
> > > > > 
> > > > > Could you please provide an example of those warning an what
> > > > > is
> > > > > trigging
> > > > > those?
> > > > > 
> > > > > Thanks and best regards,
> > > > > Alexander
> > > > 
> > > > Sure, here is a snipped from dmesg.??I think this is happening
> > > > because
> > > > the entire Raspbian OS is compiled with a custom gcc compiler
> > > > that
> > > > is
> > > > targeting arm6+VFP.
> > > > 
> > > > I can double check, but I think the instructions are being
> > > > emulated
> > > > in
> > > > hardware so they are just filling the log and slowing things
> > > > down.
> > > > 
> > > 
> > > You can disable the emulation by doing
> > > 
> > > echo 2 >/proc/sys/abi/setend
> > > echo 2 >/proc/sys/abi/cp15_barrier
> > 
> > I don't want to disable the emulation since I want to run old
> > binaries.
> > ???I just want to disable the warning...
> > 
> 
> That is exactly what this does: the A53 can execute these
> instructions
> just fine, but due to the fact that they are deprecated by the
> architecture, they are trapped and emulated by default.

OK, now I understand.

Sounds like what I want is to turn on hardware emulation when running
old binaries since collecting data is pointless.  That's kind of part
of the hardware spoofing I'm looking into.  

Alot of this seems to be missing on arm64.

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 09:43 +0000, Ard Biesheuvel wrote:
> On 22 January 2017 at 09:38, Michael Zoran <mzoran@crowfest.net>
> wrote:
> > On Sun, 2017-01-22 at 17:05 +0800, Jisheng Zhang wrote:
> > > On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:
> > > 
> > > > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > > > Hi Michael,
> > > > > 
> > > > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
> > > > > wrote:
> > > > > > I'm not sure if this if the correct place to be asking
> > > > > > this.???The
> > > > > > RPI
> > > > > > 3 running ARM64 is slowly reaching the point of being about
> > > > > > to
> > > > > > seriously run a 32 bit vender OS like Raspbian.??When
> > > > > > running
> > > > > > Raspbian,
> > > > > > I'm seeing a very large number(thousands) of kernel log
> > > > > > messages
> > > > > > about
> > > > > > deprecated instructions especially setend and barrier
> > > > > > instuctions.
> > > > > > This can be very annoying and is completely filling the
> > > > > > kernel
> > > > > > log.
> > > > > > 
> > > > > > I'm considering submitting a patch to add a Kconfig option
> > > > > > to
> > > > > > disable
> > > > > > these warnings with the default being to keep the warnings
> > > > > > enabled.??I
> > > > > > was wondering if such a patch could be seriously
> > > > > > considered.
> > > > > 
> > > > > Could you please provide an example of those warning an what
> > > > > is
> > > > > trigging
> > > > > those?
> > > > > 
> > > > > Thanks and best regards,
> > > > > Alexander
> > > > 
> > > > Sure, here is a snipped from dmesg.??I think this is happening
> > > > because
> > > > the entire Raspbian OS is compiled with a custom gcc compiler
> > > > that
> > > > is
> > > > targeting arm6+VFP.
> > > 
> > > IMHO, this is the root cause. I didn't see below warnings from
> > > dmesg
> > > with
> > > armhf debian and ubuntu If the underlying HW is armv8 compatible,
> > > it
> > > doesn't make sense to target the compiler to armv6
> > > 
> > > 
> > 
> > Advanced users can install a different OS. Beginners can't and will
> > need a single OS image for simple install.
> > 
> 
> That single OS image can simply test for the presence of
> /proc/sys/abi, and perform the writes if it is there.
> 
> > Does anybody know if these instructions are detected at runtime?
> 
> What do you mean by 'detected'?
> 
> > I'm
> > also looking into an issue with Mathmatica due to broken OS
> > detection.
> > It appears that arm64 is currently missing some of the CPU spoofing
> > that happens on other architectures...
> > 
> 
> Could you elaborate? What do you think should be there that isn't?

I'm saying that when running a ELF32 executable, the system needs to
fake the CPU architecture according to the uname system API and
/proc/cpuinfo.

Today, I run uname -a in Raspbian and I get aarch64.  I want it to
display arm6l or whatever to get Mathematica to load.

I see some code to make this work on other architectures such as X86,
but most of this appears to be unimplemented on arm64.

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 01:52 -0800, Michael Zoran wrote:
> I'm saying that when running a ELF32 executable, the system needs to
> fake the CPU architecture according to the uname system API and
> /proc/cpuinfo.
> 
> Today, I run uname -a in Raspbian and I get aarch64.? I want it to
> display arm6l or whatever to get Mathematica to load.
> 
> I see some code to make this work on other architectures such as X86,
> but most of this appears to be unimplemented on arm64.

Ideally, the system should detect the specific application and fake the
architecture according to the specific needs of that application.  But 
that sounds like I would be asking for alot there.

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 22 January 2017 at 09:52, Michael Zoran <mzoran@crowfest.net> wrote:
> On Sun, 2017-01-22 at 09:43 +0000, Ard Biesheuvel wrote:
>> On 22 January 2017 at 09:38, Michael Zoran <mzoran@crowfest.net>
>> wrote:
>> > On Sun, 2017-01-22 at 17:05 +0800, Jisheng Zhang wrote:
>> > > On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:
>> > >
>> > > > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
>> > > > > Hi Michael,
>> > > > >
>> > > > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
>> > > > > wrote:
>> > > > > > I'm not sure if this if the correct place to be asking
>> > > > > > this.   The
>> > > > > > RPI
>> > > > > > 3 running ARM64 is slowly reaching the point of being about
>> > > > > > to
>> > > > > > seriously run a 32 bit vender OS like Raspbian.  When
>> > > > > > running
>> > > > > > Raspbian,
>> > > > > > I'm seeing a very large number(thousands) of kernel log
>> > > > > > messages
>> > > > > > about
>> > > > > > deprecated instructions especially setend and barrier
>> > > > > > instuctions.
>> > > > > > This can be very annoying and is completely filling the
>> > > > > > kernel
>> > > > > > log.
>> > > > > >
>> > > > > > I'm considering submitting a patch to add a Kconfig option
>> > > > > > to
>> > > > > > disable
>> > > > > > these warnings with the default being to keep the warnings
>> > > > > > enabled.  I
>> > > > > > was wondering if such a patch could be seriously
>> > > > > > considered.
>> > > > >
>> > > > > Could you please provide an example of those warning an what
>> > > > > is
>> > > > > trigging
>> > > > > those?
>> > > > >
>> > > > > Thanks and best regards,
>> > > > > Alexander
>> > > >
>> > > > Sure, here is a snipped from dmesg.  I think this is happening
>> > > > because
>> > > > the entire Raspbian OS is compiled with a custom gcc compiler
>> > > > that
>> > > > is
>> > > > targeting arm6+VFP.
>> > >
>> > > IMHO, this is the root cause. I didn't see below warnings from
>> > > dmesg
>> > > with
>> > > armhf debian and ubuntu If the underlying HW is armv8 compatible,
>> > > it
>> > > doesn't make sense to target the compiler to armv6
>> > >
>> > >
>> >
>> > Advanced users can install a different OS. Beginners can't and will
>> > need a single OS image for simple install.
>> >
>>
>> That single OS image can simply test for the presence of
>> /proc/sys/abi, and perform the writes if it is there.
>>
>> > Does anybody know if these instructions are detected at runtime?
>>
>> What do you mean by 'detected'?
>>
>> > I'm
>> > also looking into an issue with Mathmatica due to broken OS
>> > detection.
>> > It appears that arm64 is currently missing some of the CPU spoofing
>> > that happens on other architectures...
>> >
>>
>> Could you elaborate? What do you think should be there that isn't?
>
> I'm saying that when running a ELF32 executable, the system needs to
> fake the CPU architecture according to the uname system API and
> /proc/cpuinfo.
>
> Today, I run uname -a in Raspbian and I get aarch64.  I want it to
> display arm6l or whatever to get Mathematica to load.
>
> I see some code to make this work on other architectures such as X86,
> but most of this appears to be unimplemented on arm64.
>

Did you try linux32?

pi at raspberrypi:~$ uname -a
Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
WET 2017 aarch64 GNU/Linux
pi at raspberrypi:~ $ linux32 uname -a
Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
WET 2017 armv8l GNU/Linux

If the app in question cannot deal with the armv8l personality, the
app should be fixed instead.

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 10:54 +0000, Ard Biesheuvel wrote:
> On 22 January 2017 at 09:52, Michael Zoran <mzoran@crowfest.net>
> wrote:
> > On Sun, 2017-01-22 at 09:43 +0000, Ard Biesheuvel wrote:
> > > On 22 January 2017 at 09:38, Michael Zoran <mzoran@crowfest.net>
> > > wrote:
> > > > On Sun, 2017-01-22 at 17:05 +0800, Jisheng Zhang wrote:
> > > > > On Sun, 22 Jan 2017 00:58:48 -0800 Michael Zoran wrote:
> > > > > 
> > > > > > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > > > > > Hi Michael,
> > > > > > > 
> > > > > > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael
> > > > > > > Zoran
> > > > > > > wrote:
> > > > > > > > I'm not sure if this if the correct place to be asking
> > > > > > > > this.???The
> > > > > > > > RPI
> > > > > > > > 3 running ARM64 is slowly reaching the point of being
> > > > > > > > about
> > > > > > > > to
> > > > > > > > seriously run a 32 bit vender OS like Raspbian.??When
> > > > > > > > running
> > > > > > > > Raspbian,
> > > > > > > > I'm seeing a very large number(thousands) of kernel log
> > > > > > > > messages
> > > > > > > > about
> > > > > > > > deprecated instructions especially setend and barrier
> > > > > > > > instuctions.
> > > > > > > > This can be very annoying and is completely filling the
> > > > > > > > kernel
> > > > > > > > log.
> > > > > > > > 
> > > > > > > > I'm considering submitting a patch to add a Kconfig
> > > > > > > > option
> > > > > > > > to
> > > > > > > > disable
> > > > > > > > these warnings with the default being to keep the
> > > > > > > > warnings
> > > > > > > > enabled.??I
> > > > > > > > was wondering if such a patch could be seriously
> > > > > > > > considered.
> > > > > > > 
> > > > > > > Could you please provide an example of those warning an
> > > > > > > what
> > > > > > > is
> > > > > > > trigging
> > > > > > > those?
> > > > > > > 
> > > > > > > Thanks and best regards,
> > > > > > > Alexander
> > > > > > 
> > > > > > Sure, here is a snipped from dmesg.??I think this is
> > > > > > happening
> > > > > > because
> > > > > > the entire Raspbian OS is compiled with a custom gcc
> > > > > > compiler
> > > > > > that
> > > > > > is
> > > > > > targeting arm6+VFP.
> > > > > 
> > > > > IMHO, this is the root cause. I didn't see below warnings
> > > > > from
> > > > > dmesg
> > > > > with
> > > > > armhf debian and ubuntu If the underlying HW is armv8
> > > > > compatible,
> > > > > it
> > > > > doesn't make sense to target the compiler to armv6
> > > > > 
> > > > > 
> > > > 
> > > > Advanced users can install a different OS. Beginners can't and
> > > > will
> > > > need a single OS image for simple install.
> > > > 
> > > 
> > > That single OS image can simply test for the presence of
> > > /proc/sys/abi, and perform the writes if it is there.
> > > 
> > > > Does anybody know if these instructions are detected at
> > > > runtime?
> > > 
> > > What do you mean by 'detected'?
> > > 
> > > > I'm
> > > > also looking into an issue with Mathmatica due to broken OS
> > > > detection.
> > > > It appears that arm64 is currently missing some of the CPU
> > > > spoofing
> > > > that happens on other architectures...
> > > > 
> > > 
> > > Could you elaborate? What do you think should be there that
> > > isn't?
> > 
> > I'm saying that when running a ELF32 executable, the system needs
> > to
> > fake the CPU architecture according to the uname system API and
> > /proc/cpuinfo.
> > 
> > Today, I run uname -a in Raspbian and I get aarch64.??I want it to
> > display arm6l or whatever to get Mathematica to load.
> > 
> > I see some code to make this work on other architectures such as
> > X86,
> > but most of this appears to be unimplemented on arm64.
> > 
> 
> Did you try linux32?
> 
> pi at raspberrypi:~$ uname -a
> Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
> WET 2017 aarch64 GNU/Linux
> pi at raspberrypi:~ $ linux32 uname -a
> Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
> WET 2017 armv8l GNU/Linux
> 
> If the app in question cannot deal with the armv8l personality, the
> app should be fixed instead.

Thanks, I didn't know about the tool.

I'm looking at the code in arch/arm64/include/asm/elf.h. I'm looking at
the COMPAT_SET_PERSONALITY macro.  It appears to be broken.  It seems 
like it should have a call to set_personality with PER_LINUX32.  

If I look in include/uapi/linux/personality.h, I see some very
interesting things. Quite the complex set of options I would say.

/*
?* Flags for bug emulation.
?*
?* These occupy the top three bytes.
?*/
enum {
	UNAME26	=???????????????0x0020000,
	ADDR_NO_RANDOMIZE =?	0x0040000,	/* disable
randomization of VA space */
	FDPIC_FUNCPTRS =	0x0080000,	/* userspace function
ptrs point to descriptors
						?* (signal handling)
						?*/
	MMAP_PAGE_ZERO =	0x0100000,
	ADDR_COMPAT_LAYOUT =	0x0200000,
	READ_IMPLIES_EXEC =	0x0400000,
	ADDR_LIMIT_32BIT =	0x0800000,
	SHORT_INODE =		0x1000000,
	WHOLE_SECONDS =		0x2000000,
	STICKY_TIMEOUTS	=	0x4000000,
	ADDR_LIMIT_3GB =?	0x8000000,
};

/*
?* Security-relevant compatibility flags that must be
?* cleared upon setuid or setgid exec:
?*/
#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC??| \
			????ADDR_NO_RANDOMIZE??| \
			????ADDR_COMPAT_LAYOUT | \
			????MMAP_PAGE_ZERO)

/*
?* Personality types.
?*
?* These go in the low byte.??Avoid using the top bit, it will
?* conflict with error returns.
?*/
enum {
	PER_LINUX =		0x0000,
	PER_LINUX_32BIT =	0x0000 | ADDR_LIMIT_32BIT,
	PER_LINUX_FDPIC =	0x0000 | FDPIC_FUNCPTRS,
	PER_SVR4 =		0x0001 | STICKY_TIMEOUTS |
MMAP_PAGE_ZERO,
	PER_SVR3 =		0x0002 | STICKY_TIMEOUTS |
SHORT_INODE,
	PER_SCOSVR3 =		0x0003 | STICKY_TIMEOUTS |
					?WHOLE_SECONDS | SHORT_INODE,
	PER_OSR5 =		0x0003 | STICKY_TIMEOUTS |
WHOLE_SECONDS,
	PER_WYSEV386 =		0x0004 | STICKY_TIMEOUTS |
SHORT_INODE,
	PER_ISCR4 =		0x0005 | STICKY_TIMEOUTS,
	PER_BSD =		0x0006,
	PER_SUNOS =		0x0006 | STICKY_TIMEOUTS,
	PER_XENIX =		0x0007 | STICKY_TIMEOUTS |
SHORT_INODE,
	PER_LINUX32 =		0x0008,
	PER_LINUX32_3GB =	0x0008 | ADDR_LIMIT_3GB,
	PER_IRIX32 =		0x0009 | STICKY_TIMEOUTS,/* IRIX5
32-bit */
	PER_IRIXN32 =		0x000a | STICKY_TIMEOUTS,/* IRIX6
new 32-bit */
	PER_IRIX64 =		0x000b | STICKY_TIMEOUTS,/* IRIX6
64-bit */
	PER_RISCOS =		0x000c,
	PER_SOLARIS =		0x000d | STICKY_TIMEOUTS,
	PER_UW7 =		0x000e | STICKY_TIMEOUTS |
MMAP_PAGE_ZERO,
	PER_OSF4 =		0x000f,			?/*
OSF/1 v4 */
	PER_HPUX =		0x0010,
	PER_MASK =		0x00ff,
};

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 03:05 -0800, Michael Zoran wrote:
> On Sun, 2017-01-22 at 10:54 +0000, Ard Biesheuvel wrote:
> > Did you try linux32?
> > 
> > pi at raspberrypi:~$ uname -a
> > Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
> > WET 2017 aarch64 GNU/Linux
> > pi at raspberrypi:~ $ linux32 uname -a
> > Linux raspberrypi 4.10.0-rc3-v8+ #3 SMP PREEMPT Sun Jan 15 15:22:12
> > WET 2017 armv8l GNU/Linux
> > 
> > If the app in question cannot deal with the armv8l personality, the
> > app should be fixed instead.
> 
> Thanks, I didn't know about the tool.
> 
> I'm looking at the code in arch/arm64/include/asm/elf.h. I'm looking
> at
> the COMPAT_SET_PERSONALITY macro.??It appears to be broken.??It
> seems?
> like it should have a call to set_personality with PER_LINUX32.??
> 
> If I look in include/uapi/linux/personality.h, I see some very
> interesting things. Quite the complex set of options I would say.
> 
> /*
> ?* Flags for bug emulation.
> ?*
> ?* These occupy the top three bytes.
> ?*/
> enum {
> 	UNAME26	=???????????????0x0020000,
> 	ADDR_NO_RANDOMIZE =?	0x0040000,	/* disable
> randomization of VA space */
> 	FDPIC_FUNCPTRS =	0x0080000,	/* userspace function
> ptrs point to descriptors
> 						?* (signal handling)
> 						?*/
> 	MMAP_PAGE_ZERO =	0x0100000,
> 	ADDR_COMPAT_LAYOUT =	0x0200000,
> 	READ_IMPLIES_EXEC =	0x0400000,
> 	ADDR_LIMIT_32BIT =	0x0800000,
> 	SHORT_INODE =		0x1000000,
> 	WHOLE_SECONDS =		0x2000000,
> 	STICKY_TIMEOUTS	=	0x4000000,
> 	ADDR_LIMIT_3GB =?	0x8000000,
> };
> 
> /*
> ?* Security-relevant compatibility flags that must be
> ?* cleared upon setuid or setgid exec:
> ?*/
> #define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC??| \
> 			????ADDR_NO_RANDOMIZE??| \
> 			????ADDR_COMPAT_LAYOUT | \
> 			????MMAP_PAGE_ZERO)
> 
> /*
> ?* Personality types.
> ?*
> ?* These go in the low byte.??Avoid using the top bit, it will
> ?* conflict with error returns.
> ?*/
> enum {
> 	PER_LINUX =		0x0000,
> 	PER_LINUX_32BIT =	0x0000 | ADDR_LIMIT_32BIT,
> 	PER_LINUX_FDPIC =	0x0000 | FDPIC_FUNCPTRS,
> 	PER_SVR4 =		0x0001 | STICKY_TIMEOUTS |
> MMAP_PAGE_ZERO,
> 	PER_SVR3 =		0x0002 | STICKY_TIMEOUTS |
> SHORT_INODE,
> 	PER_SCOSVR3 =		0x0003 | STICKY_TIMEOUTS |
> 					?WHOLE_SECONDS | SHORT_INODE,
> 	PER_OSR5 =		0x0003 | STICKY_TIMEOUTS |
> WHOLE_SECONDS,
> 	PER_WYSEV386 =		0x0004 | STICKY_TIMEOUTS |
> SHORT_INODE,
> 	PER_ISCR4 =		0x0005 | STICKY_TIMEOUTS,
> 	PER_BSD =		0x0006,
> 	PER_SUNOS =		0x0006 | STICKY_TIMEOUTS,
> 	PER_XENIX =		0x0007 | STICKY_TIMEOUTS |
> SHORT_INODE,
> 	PER_LINUX32 =		0x0008,
> 	PER_LINUX32_3GB =	0x0008 | ADDR_LIMIT_3GB,
> 	PER_IRIX32 =		0x0009 | STICKY_TIMEOUTS,/* IRIX5
> 32-bit */
> 	PER_IRIXN32 =		0x000a | STICKY_TIMEOUTS,/* IRIX6
> new 32-bit */
> 	PER_IRIX64 =		0x000b | STICKY_TIMEOUTS,/* IRIX6
> 64-bit */
> 	PER_RISCOS =		0x000c,
> 	PER_SOLARIS =		0x000d | STICKY_TIMEOUTS,
> 	PER_UW7 =		0x000e | STICKY_TIMEOUTS |
> MMAP_PAGE_ZERO,
> 	PER_OSF4 =		0x000f,			?/*
> OSF/1 v4 */
> 	PER_HPUX =		0x0010,
> 	PER_MASK =		0x00ff,
> };
> 

OK, I got mathematica to load without using the linux32 tool.

I changed the macro to this. 

#define COMPAT_SET_PERSONALITY(ex)					
\
({									
\
	set_bit(TIF_32BIT, &current->mm->context.flags);		
\
	set_thread_flag(TIF_32BIT);					
\
	set_personality(current->personality??=
PER_LINUX32);???????????\
})

 But I'm not sure that is really the correct set of options.   Why not
PER_LINUX32_3GB or PER_LINUX_32BIT?

ARM64: Disabling warnings about deprecated armv8 instructions

[Alexander Stein]

 On Sunday, January 22, 2017, 9:09:37 AM CET Ard Biesheuvel wrote:
> On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net> wrote:
> > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> >> Hi Michael,
> >> 
> >> On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran wrote:
> >> > I'm not sure if this if the correct place to be asking this.   The
> >> > RPI
> >> > 3 running ARM64 is slowly reaching the point of being about to
> >> > seriously run a 32 bit vender OS like Raspbian.  When running
> >> > Raspbian,
> >> > I'm seeing a very large number(thousands) of kernel log messages
> >> > about
> >> > deprecated instructions especially setend and barrier instuctions.
> >> > This can be very annoying and is completely filling the kernel log.
> >> > 
> >> > I'm considering submitting a patch to add a Kconfig option to
> >> > disable
> >> > these warnings with the default being to keep the warnings
> >> > enabled.  I
> >> > was wondering if such a patch could be seriously considered.
> >> 
> >> Could you please provide an example of those warning an what is
> >> trigging
> >> those?
> >> 
> >> Thanks and best regards,
> >> Alexander
> > 
> > Sure, here is a snipped from dmesg.  I think this is happening because
> > the entire Raspbian OS is compiled with a custom gcc compiler that is
> > targeting arm6+VFP.
> > 
> > I can double check, but I think the instructions are being emulated in
> > hardware so they are just filling the log and slowing things down.
> > 
> > [10685.558480] cp15barrier_handler: 197896 callbacks suppressed
> > [10685.558487] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf707fe9c
> > [10685.558504] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7015944
> > [10685.558511] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7012494
> > [10685.558518] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf70159b4
> > [10685.558527] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7011478
> > [10685.558533] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf70114e8
> > [10685.558540] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7015944
> > [10685.558547] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7012494
> > [10685.558553] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf70159b4
> > [10685.558560] "Xorg" (656) uses deprecated CP15 Barrier instruction at
> > 0xf7011478
> > [10685.559179] compat_setend_handler: 1078 callbacks suppressed
> > [10685.559188] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a66f4
> > [10685.559196] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a6bd8
> > [10685.559209] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a66f4
> > [10685.559216] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a6bd8
> > [10685.559231] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a66f4
> > [10685.559237] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a6bd8
> > [10685.559246] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a66f4
> > [10685.559253] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a6bd8
> > [10685.559269] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a66f4
> > [10685.559276] "systemd-journal" (138) uses deprecated setend
> > instruction at 0xf76a6bd8
> 
> You can disable the emulation by doing
> 
> echo 2 >/proc/sys/abi/setend
> echo 2 >/proc/sys/abi/cp15_barrier

This reminds me of /proc/cpu/alignment to detect alignment problems in your 
application. Although armv6+ can handle unaligned access in most (!) cases you 
might want to trap thos cases. I would consider this a similar way.
IMHO raspbian, still supporting raspberry pi 1 (armv6), should silence those 
warnings.

Best regards,
Alexander

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 12:46 +0100, Alexander Stein wrote:
> ?On Sunday, January 22, 2017, 9:09:37 AM CET Ard Biesheuvel wrote:
> > On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net>
> > wrote:
> > > On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
> > > > Hi Michael,
> > > > 
> > > > On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
> > > > wrote:
> > > > > I'm not sure if this if the correct place to be asking
> > > > > this.???The
> > > > > RPI
> > > > > 3 running ARM64 is slowly reaching the point of being about
> > > > > to
> > > > > seriously run a 32 bit vender OS like Raspbian.??When running
> > > > > Raspbian,
> > > > > I'm seeing a very large number(thousands) of kernel log
> > > > > messages
> > > > > about
> > > > > deprecated instructions especially setend and barrier
> > > > > instuctions.
> > > > > This can be very annoying and is completely filling the
> > > > > kernel log.
> > > > > 
> > > > > I'm considering submitting a patch to add a Kconfig option to
> > > > > disable
> > > > > these warnings with the default being to keep the warnings
> > > > > enabled.??I
> > > > > was wondering if such a patch could be seriously considered.
> > > > 
> > > > Could you please provide an example of those warning an what is
> > > > trigging
> > > > those?
> > > > 
> > > > Thanks and best regards,
> > > > Alexander
> > > 
> > > Sure, here is a snipped from dmesg.??I think this is happening
> > > because
> > > the entire Raspbian OS is compiled with a custom gcc compiler
> > > that is
> > > targeting arm6+VFP.
> > > 
> > > I can double check, but I think the instructions are being
> > > emulated in
> > > hardware so they are just filling the log and slowing things
> > > down.
> > > 
> > > [10685.558480] cp15barrier_handler: 197896 callbacks suppressed
> > > [10685.558487] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf707fe9c
> > > [10685.558504] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7015944
> > > [10685.558511] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7012494
> > > [10685.558518] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf70159b4
> > > [10685.558527] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7011478
> > > [10685.558533] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf70114e8
> > > [10685.558540] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7015944
> > > [10685.558547] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7012494
> > > [10685.558553] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf70159b4
> > > [10685.558560] "Xorg" (656) uses deprecated CP15 Barrier
> > > instruction at
> > > 0xf7011478
> > > [10685.559179] compat_setend_handler: 1078 callbacks suppressed
> > > [10685.559188] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a66f4
> > > [10685.559196] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a6bd8
> > > [10685.559209] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a66f4
> > > [10685.559216] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a6bd8
> > > [10685.559231] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a66f4
> > > [10685.559237] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a6bd8
> > > [10685.559246] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a66f4
> > > [10685.559253] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a6bd8
> > > [10685.559269] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a66f4
> > > [10685.559276] "systemd-journal" (138) uses deprecated setend
> > > instruction at 0xf76a6bd8
> > 
> > You can disable the emulation by doing
> > 
> > echo 2 >/proc/sys/abi/setend
> > echo 2 >/proc/sys/abi/cp15_barrier
> 
> This reminds me of /proc/cpu/alignment to detect alignment problems
> in your?
> application. Although armv6+ can handle unaligned access in most (!)
> cases you?
> might want to trap thos cases. I would consider this a similar way.
> IMHO raspbian, still supporting raspberry pi 1 (armv6), should
> silence those?
> warnings.
> 
> Best regards,
> Alexander
> 

Thanks, but I see multiple ways this could be solved which is partially
why I sent out the initial e-mail.

Here are just a few of the options.
1. Add a .config option to silence the warnings.
2. Detect the binary type to detectermine if it should be silenced.
3. #ifdef out the complaining code in downstream sources.
4. Have various distributions write to /proc/sys/abi/* at system boot.

The list is probably endless.

And I think this is closely related to the other topic of setting the
linux personality based on detection of the binary.

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

> On 22 Jan 2017, at 12:21, Michael Zoran <mzoran@crowfest.net> wrote:
> 
>> On Sun, 2017-01-22 at 12:46 +0100, Alexander Stein wrote:
>>>  On Sunday, January 22, 2017, 9:09:37 AM CET Ard Biesheuvel wrote:
>>> On 22 January 2017 at 08:58, Michael Zoran <mzoran@crowfest.net>
>>> wrote:
>>>> On Sun, 2017-01-22 at 09:52 +0100, Alexander Stein wrote:
>>>>> Hi Michael,
>>>>> 
>>>>> On Sunday, January 22, 2017, 12:07:04 AM CET Michael Zoran
>>>>> wrote:
>>>>>> I'm not sure if this if the correct place to be asking
>>>>>> this.   The
>>>>>> RPI
>>>>>> 3 running ARM64 is slowly reaching the point of being about
>>>>>> to
>>>>>> seriously run a 32 bit vender OS like Raspbian.  When running
>>>>>> Raspbian,
>>>>>> I'm seeing a very large number(thousands) of kernel log
>>>>>> messages
>>>>>> about
>>>>>> deprecated instructions especially setend and barrier
>>>>>> instuctions.
>>>>>> This can be very annoying and is completely filling the
>>>>>> kernel log.
>>>>>> 
>>>>>> I'm considering submitting a patch to add a Kconfig option to
>>>>>> disable
>>>>>> these warnings with the default being to keep the warnings
>>>>>> enabled.  I
>>>>>> was wondering if such a patch could be seriously considered.
>>>>> 
>>>>> Could you please provide an example of those warning an what is
>>>>> trigging
>>>>> those?
>>>>> 
>>>>> Thanks and best regards,
>>>>> Alexander
>>>> 
>>>> Sure, here is a snipped from dmesg.  I think this is happening
>>>> because
>>>> the entire Raspbian OS is compiled with a custom gcc compiler
>>>> that is
>>>> targeting arm6+VFP.
>>>> 
>>>> I can double check, but I think the instructions are being
>>>> emulated in
>>>> hardware so they are just filling the log and slowing things
>>>> down.
>>>> 
>>>> [10685.558480] cp15barrier_handler: 197896 callbacks suppressed
>>>> [10685.558487] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf707fe9c
>>>> [10685.558504] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7015944
>>>> [10685.558511] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7012494
>>>> [10685.558518] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf70159b4
>>>> [10685.558527] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7011478
>>>> [10685.558533] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf70114e8
>>>> [10685.558540] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7015944
>>>> [10685.558547] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7012494
>>>> [10685.558553] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf70159b4
>>>> [10685.558560] "Xorg" (656) uses deprecated CP15 Barrier
>>>> instruction at
>>>> 0xf7011478
>>>> [10685.559179] compat_setend_handler: 1078 callbacks suppressed
>>>> [10685.559188] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a66f4
>>>> [10685.559196] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a6bd8
>>>> [10685.559209] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a66f4
>>>> [10685.559216] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a6bd8
>>>> [10685.559231] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a66f4
>>>> [10685.559237] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a6bd8
>>>> [10685.559246] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a66f4
>>>> [10685.559253] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a6bd8
>>>> [10685.559269] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a66f4
>>>> [10685.559276] "systemd-journal" (138) uses deprecated setend
>>>> instruction at 0xf76a6bd8
>>> 
>>> You can disable the emulation by doing
>>> 
>>> echo 2 >/proc/sys/abi/setend
>>> echo 2 >/proc/sys/abi/cp15_barrier
>> 
>> This reminds me of /proc/cpu/alignment to detect alignment problems
>> in your 
>> application. Although armv6+ can handle unaligned access in most (!)
>> cases you 
>> might want to trap thos cases. I would consider this a similar way.

Emulating unaligned access in the ARM kernel was a mistake: it even emulates unaligned accesses for instructions like ldm and ldrd, which require word alignment at the hardware level even in the latest v8 version of the architecture. In contrast, the v8 deprecation warnings are about enforcing compliance.

>> IMHO raspbian, still supporting raspberry pi 1 (armv6), should
>> silence those 
>> warnings.
>> 
>> Best regards,
>> Alexander
>> 
> 
> Thanks, but I see multiple ways this could be solved which is partially
> why I sent out the initial e-mail.
> 
> Here are just a few of the options.
> 1. Add a .config option to silence the warning.

It is perfectly reasonable for a kernel that targets architecture version 8 and later to warn by default about the use of instructions that were deprecated already in v7, especially given the runtime knob to control it.

> 2. Detect the binary type to detectermine if it should be silenced.

The controls are system wide, not per process. And I think the somewhat unconventional requirement to run a v6 compatible userland justifies adding a line to the boot script that simply disarms all the deprecation warnings.

Any political differences in the rpi project regarding support of the 64 bit kernel are not upstream's problem imo

> 3. #ifdef out the complaining code in downstream sources.
> 4. Have various distributions write to /proc/sys/abi/* at system boot.
> 
> The list is probably endless.
> 

No it is not. And presenting them like this suggests that they are equally controversial and intrusive, which is really not the case.

> And I think this is closely related to the other topic of setting the
> linux personality based on detection of the binary.
> 

I wonder why Mathematica cares about the personality. If it makes inferences about the architecture level to decide which instructions to use, it is clearly abusing the facility. Any clue?

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Sun, 2017-01-22 at 13:01 +0000, Ard Biesheuvel wrote:
> > On 22 Jan 2017, at 12:21, Michael Zoran <mzoran@crowfest.net>
> > wrote:
> 
> > 2. Detect the binary type to detectermine if it should be silenced.
> 
> The controls are system wide, not per process. And I think the
> somewhat unconventional requirement to run a v6 compatible userland
> justifies adding a line to the boot script that simply disarms all
> the deprecation warnings.
> 

    It depends on the point of view of the arm architecture.  One point
of view if that if you have a new 64 bit application with access to
more feature, it has to be compiled with new instructions so no reason
to have the old around.  But if you have an old 32 bit application,
then it keeps working.

> Any political differences in the rpi project regarding support of the
> 64 bit kernel are not upstream's problem imo
> 

    I am in no way associated with the rpi project or the organization.
 I receive absolutely nothing from them and they are not supporting 64
bit at all other then as a hobbiest/experimental project.  

    I'm just a very interested enthusiast with a bit of time on my hand
now that finds 64 bit interesting. I found the idea of getting 32 bit
Raspbian to work as interesting.

> > 
> 
> I wonder why Mathematica cares about the personality. If it makes
> inferences about the architecture level to decide which instructions
> to use, it is clearly abusing the facility. Any clue?
> 

   No idea really.  It may have something to do with licensing
requirements since it's targeted for education. In the sake of not
stepping on any toes I have no intention of submitting any patches or
changes to the personality because of that.

  The personality issue is more an arm architcture issue and I am
quickly seeing is beyond the scope of what I'm trying to accomplish.

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 22 January 2017 at 14:02, Michael Zoran <mzoran@crowfest.net> wrote:
> On Sun, 2017-01-22 at 13:01 +0000, Ard Biesheuvel wrote:
>> > On 22 Jan 2017, at 12:21, Michael Zoran <mzoran@crowfest.net>
>> > wrote:
>>
>> > 2. Detect the binary type to detectermine if it should be silenced.
>>
>> The controls are system wide, not per process. And I think the
>> somewhat unconventional requirement to run a v6 compatible userland
>> justifies adding a line to the boot script that simply disarms all
>> the deprecation warnings.
>>
>
>     It depends on the point of view of the arm architecture.  One point
> of view if that if you have a new 64 bit application with access to
> more feature, it has to be compiled with new instructions so no reason
> to have the old around.  But if you have an old 32 bit application,
> then it keeps working.
>

Well, it is of course a tradeoff between the loss of functionality
versus the cost of keeping the feature supported. I am not a hardware
designer, but it is not difficult to imagine how the fact that the
endianness of a process may change at any point during its execution
can complicate a modern pipeline significantly, given that it may have
many instructions in flight in various stages of execution, including
memory accesses that need to be restarted if the endianness changes.

So that is why the setend instruction is deprecated, which in this
case also means support for it is no longer mandatory.

>> Any political differences in the rpi project regarding support of the
>> 64 bit kernel are not upstream's problem imo
>>
>
>     I am in no way associated with the rpi project or the organization.
>  I receive absolutely nothing from them and they are not supporting 64
> bit at all other then as a hobbiest/experimental project.
>
>     I'm just a very interested enthusiast with a bit of time on my hand
> now that finds 64 bit interesting. I found the idea of getting 32 bit
> Raspbian to work as interesting.
>

I agree. I am also an enthusiast (although a paid one). Recently, I
have been looking into improving the performance AES in the arm64
kernel, specifically because the Raspberry Pi 3 does not support the
new v8 AES instructions.

>> >
>>
>> I wonder why Mathematica cares about the personality. If it makes
>> inferences about the architecture level to decide which instructions
>> to use, it is clearly abusing the facility. Any clue?
>>
>
>    No idea really.  It may have something to do with licensing
> requirements since it's targeted for education. In the sake of not
> stepping on any toes I have no intention of submitting any patches or
> changes to the personality because of that.
>
>   The personality issue is more an arm architcture issue and I am
> quickly seeing is beyond the scope of what I'm trying to accomplish.

ARM64: Disabling warnings about deprecated armv8 instructions

[Russell King - ARM Linux]

On Sun, Jan 22, 2017 at 01:01:53PM +0000, Ard Biesheuvel wrote:
> Emulating unaligned access in the ARM kernel was a mistake: it even
> emulates unaligned accesses for instructions like ldm and ldrd, which
> require word alignment at the hardware level even in the latest v8
> version of the architecture. In contrast, the v8 deprecation warnings
> are about enforcing compliance.

Ard, you're totally wrong on the unaligned access thing.  Unaligned
accesses are a fundamental requirement of the kernel's networking
stack.  If you don't have support for unaligned accesses, then you
don't have network support - it's as simple as that.

So, in order for ARMv5 and earlier to have network support, there
was no option to add support for emulating those accesses.

The dubious thing was whether to add that for userspace as well.
Since soo many applications were broken at the time, and ARM wasn't
a sufficiently large community for the applications people to care
one shit about, the applications people weren't going to fix their
code to avoid unaligned accesses.

So, back in the 1990s, we were stuck between having broken userspace
and a huge amount of effort needed to maintain ARM specific patches
out of tree for lots of applications, or functional userspace.

Today, the ARM architecture has moved on a long way, and application
people care about whether their stuff works on the ARM architecture.
It wasn't like that when the unaligned emulation was added.

It was not a mistake.  It's one of the reasons why ARM has got where
it is today, and probably why the light was finally seen to add
hardware support for unaligned accesses to the later CPU architectures.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 30 January 2017 at 14:13, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Sun, Jan 22, 2017 at 01:01:53PM +0000, Ard Biesheuvel wrote:
>> Emulating unaligned access in the ARM kernel was a mistake: it even
>> emulates unaligned accesses for instructions like ldm and ldrd, which
>> require word alignment at the hardware level even in the latest v8
>> version of the architecture. In contrast, the v8 deprecation warnings
>> are about enforcing compliance.
>
> Ard, you're totally wrong on the unaligned access thing.  Unaligned
> accesses are a fundamental requirement of the kernel's networking
> stack.  If you don't have support for unaligned accesses, then you
> don't have network support - it's as simple as that.
>
> So, in order for ARMv5 and earlier to have network support, there
> was no option to add support for emulating those accesses.
>

I wasn't aware of that. But does that mean it is simply too much work
to remove those alignment assumptions? It does not seem like a
fundamental networking issue to me, but rather a tacit assumption that
has infected the software implementation.

> The dubious thing was whether to add that for userspace as well.
> Since soo many applications were broken at the time, and ARM wasn't
> a sufficiently large community for the applications people to care
> one shit about, the applications people weren't going to fix their
> code to avoid unaligned accesses.
>
> So, back in the 1990s, we were stuck between having broken userspace
> and a huge amount of effort needed to maintain ARM specific patches
> out of tree for lots of applications, or functional userspace.
>

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.

> Today, the ARM architecture has moved on a long way, and application
> people care about whether their stuff works on the ARM architecture.
> It wasn't like that when the unaligned emulation was added.
>
> It was not a mistake.  It's one of the reasons why ARM has got where
> it is today, and probably why the light was finally seen to add
> hardware support for unaligned accesses to the later CPU architectures.
>

OK, I stand corrected. I haven't been around nearly as long as Russell
or some others here on LAKML, so I don't have the historical
background. On the arm64 side, it is *much* easier to take a normative
stance, given how new it is.

ARM64: Disabling warnings about deprecated armv8 instructions

[Måns Rullgård]

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

> On 30 January 2017 at 14:13, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Sun, Jan 22, 2017 at 01:01:53PM +0000, Ard Biesheuvel wrote:
>>> Emulating unaligned access in the ARM kernel was a mistake: it even
>>> emulates unaligned accesses for instructions like ldm and ldrd, which
>>> require word alignment at the hardware level even in the latest v8
>>> version of the architecture. In contrast, the v8 deprecation warnings
>>> are about enforcing compliance.
>>
>> Ard, you're totally wrong on the unaligned access thing.  Unaligned
>> accesses are a fundamental requirement of the kernel's networking
>> stack.  If you don't have support for unaligned accesses, then you
>> don't have network support - it's as simple as that.
>>
>> So, in order for ARMv5 and earlier to have network support, there
>> was no option to add support for emulating those accesses.
>>
>
> I wasn't aware of that.

Not even David Miller is "aware" of that.  Then again, we're living in a
world of "alternative facts" now.

-- 
M?ns Rullg?rd

ARM64: Disabling warnings about deprecated armv8 instructions

[Russell King - ARM Linux]

On Mon, Jan 30, 2017 at 02:50:23PM +0000, Ard Biesheuvel wrote:
> On 30 January 2017 at 14:13, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Sun, Jan 22, 2017 at 01:01:53PM +0000, Ard Biesheuvel wrote:
> >> Emulating unaligned access in the ARM kernel was a mistake: it even
> >> emulates unaligned accesses for instructions like ldm and ldrd, which
> >> require word alignment at the hardware level even in the latest v8
> >> version of the architecture. In contrast, the v8 deprecation warnings
> >> are about enforcing compliance.
> >
> > Ard, you're totally wrong on the unaligned access thing.  Unaligned
> > accesses are a fundamental requirement of the kernel's networking
> > stack.  If you don't have support for unaligned accesses, then you
> > don't have network support - it's as simple as that.
> >
> > So, in order for ARMv5 and earlier to have network support, there
> > was no option to add support for emulating those accesses.
> >
> 
> I wasn't aware of that. But does that mean it is simply too much work
> to remove those alignment assumptions? It does not seem like a
> fundamental networking issue to me, but rather a tacit assumption that
> has infected the software implementation.

When it first came up, it was discussed, and the reaction from the
networking people is that they were not going to accept any patches
that "fixed" the networking code for this issue.

They later added the NET_IP_ALIGN thing to offset received ethernet
packets by two bytes to align the 32-bit addresses in the IP header
to a natural 32-bit word boundary, which gave a performance improvement
on many platforms.  I see there has been some discussion about removing
this as there's some evidence in the opposite direction (which will
then mean that the networking stack will be pretty much guaranteed to
make unaligned accesses for every networking packet it handles.)

Then there's TCP options, which can result in unaligned accesses being
generated even when the IP headers are aligned.

Unfortunately, this is stuff from around 20 years ago, so trying to
use google to find references to it is pretty much hopeless.

However, even today, on ARMv7, the networking code still occasionally
provokes the unaligned handler:

System:         2 (nsm_get_handle+0x200/0x484)
DWord:          2

That's in a protected environment though - out in the wild of the
Internet, it's most likely a different story...

> 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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

ARM64: Disabling warnings about deprecated armv8 instructions

[Ard Biesheuvel]

On 30 January 2017 at 16:58, Russell King - ARM Linux
<linux@armlinux.org.uk> 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.

ARM64: Disabling warnings about deprecated armv8 instructions

[Eric Anholt]

Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:

> On 30 January 2017 at 16:58, Russell King - ARM Linux
> <linux@armlinux.org.uk> 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.

It sounds like you should not expose a 32-bit compat environment on
future systems without all the 32-bit instructions.  I don't see why a
future processor not having compatibility means we need to break binary
compatiblity by default for today's processors.  And yes, spamming dmesg
is definitely breakage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170130/81bc62e7/attachment.sig>

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
> On 30 January 2017 at 16:58, Russell King - ARM Linux
> <linux@armlinux.org.uk> 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.

ARM64: Disabling warnings about deprecated armv8 instructions

[Måns Rullgård]

Michael Zoran <mzoran@crowfest.net> writes:

> On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
>> 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.

Might warning once be an acceptable compromise?

-- 
M?ns Rullg?rd

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Mon, 2017-01-30 at 18:17 +0000, M?ns Rullg?rd wrote:
> Michael Zoran <mzoran@crowfest.net> writes:
> 
> > On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
> > > 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.
> 
> Might warning once be an acceptable compromise?

Absolutely!

ARM64: Disabling warnings about deprecated armv8 instructions

[Will Deacon]

On Mon, Jan 30, 2017 at 10:34:59AM -0800, Michael Zoran wrote:
> On Mon, 2017-01-30 at 18:17 +0000, M?ns Rullg?rd wrote:
> > Michael Zoran <mzoran@crowfest.net> writes:
> > > On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
> > > > 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.
> > 
> > Might warning once be an acceptable compromise?
> 
> Absolutely!

The problem with warning once is that you miss many of the places where
you're paying the cost of a trap to emulate the instruction. The purpose
of the prints is to notify the user that they're running on borrowed time:
in the next raspberry pi or the one after that, the instruction may be
removed from the hardware and every invocation will trap. The prints are
necessary to aid in code migration and are ratelimited already. If you
decide you don't like them then you can turn them off by writing to files
in sysfs and having the hardware execute the instructions for you, but
having that as the kernel default would be *less* helpful to userspace.

This was all discussed in some detail back in 2014:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/268504.html

and specifically:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/269675.html

I was initially against any emulation at all (which wasn't the right answer
to the problem), but there was a productive discussion and an agreed
solution. I'm really not keen to re-open that can of worms unless something
significant has changed.

Will

ARM64: Disabling warnings about deprecated armv8 instructions

[Michael Zoran]

On Mon, 2017-01-30 at 18:49 +0000, Will Deacon wrote:
> This was all discussed in some detail back in 2014:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/26850
> 4.html
> 
> and specifically:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/26967
> 5.html
> 
> I was initially against any emulation at all (which wasn't the right
> answer
> to the problem), but there was a productive discussion and an agreed
> solution. I'm really not keen to re-open that can of worms unless
> something
> significant has changed.
> 

Yes this is a very deep subject and it goes beyond my technical
understanding of ARM.

One point that was made in the topic is does filling up the dmesg log
really going to give an incentive to people to complain to whoever they
got the software from?  Especially in the case of beginners that may
not even know what dmesg is or what it is for?

I know moving to a single binary is a long term goal.  If I downloaded
a new version of the standard kernel and it broke my favorite piece of
software, who would I blame?  Most people would probably blame the
kernel image, not the application/software.

I know I'm mostly interested in the Raspberry PI, and that case is more
complex because the kernel, user mode software, and hardware all
originate from the same place.  But that certainly isn't the general
case for ARM.

The log once or slow down the rate of logging seems like a good
compromise.  Maybe after a certain number of logging hit, the CPU goes
back to hardware emulation if available?