Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for some issues on Arm platforms #818

Merged
merged 2 commits into from
Nov 22, 2019

Conversation

nullr0ute
Copy link
Contributor

We're seeing a few issues on Arm platforms [1], ARMv7 and aarch64, and review there's a few issues and clarifications needed around the way some of the Arm features work. This fixes up the issues seen and clarifies a few details of some of the Arm architecture quirks.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1562084

Signed-off-by: Peter Robinson pbrobinson@gmail.com

This reverts commit 6c4f746.

The reverts the commit. More details will be in the fixes for commit
73b0de0.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The change in 73b0de0 has caused a number of real world regressions
on arm32/armhfp/aarch32 users, in particular when running on ARMv8 based
hardware. There's a number of cases where software can't be installed
or the OS can't even be installed due to issues around armv7hcnl and
armv8hcnl. The NEON 'n' extension on ARMv8 hardware is not optional, so
is assumed as part of the armv8hl rpm. The crypto extensions 'c' are
optional and their implementation is widely varied, due to this the
software implementations do run time detection, the detection of this
functionality and subsquent priortisation of the 'c' extension is
incorrect, especially where the software could be running in a VM
or container and hence even in a running instance the underlying
hardware could concievably change so requiring this as a compile time
option has proved to be extremely problematic causing massive issues
with Fedora ARM.

We adjust the detection of NEON 'n' just to happen on ARMv7 where while
it was implemented it has always been problematic and never really used
and hence is a legacy implementation detail that needs to be supported
but in reality the vast majority of NEON optimisation happens at run
time in libraries where it make a difference.

In the case of the 'c' crypto extenions we have explicitly not added
this as package management functionality as it's handled effectively
with run time detection as optimisaiton and as in Fefora has just
caused regressions and issues.

Fixes RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1691430

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
@dmach
Copy link

dmach commented Oct 18, 2019

@rh-atomic-bot try

@rh-atomic-bot
Copy link

⌛ Trying commit f858089 with merge dc51f68...

rh-atomic-bot pushed a commit that referenced this pull request Oct 18, 2019
This reverts commit 6c4f746.

The reverts the commit. More details will be in the fixes for commit
73b0de0.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

Closes: #818
Approved by: <try>
rh-atomic-bot pushed a commit that referenced this pull request Oct 18, 2019
The change in 73b0de0 has caused a number of real world regressions
on arm32/armhfp/aarch32 users, in particular when running on ARMv8 based
hardware. There's a number of cases where software can't be installed
or the OS can't even be installed due to issues around armv7hcnl and
armv8hcnl. The NEON 'n' extension on ARMv8 hardware is not optional, so
is assumed as part of the armv8hl rpm. The crypto extensions 'c' are
optional and their implementation is widely varied, due to this the
software implementations do run time detection, the detection of this
functionality and subsquent priortisation of the 'c' extension is
incorrect, especially where the software could be running in a VM
or container and hence even in a running instance the underlying
hardware could concievably change so requiring this as a compile time
option has proved to be extremely problematic causing massive issues
with Fedora ARM.

We adjust the detection of NEON 'n' just to happen on ARMv7 where while
it was implemented it has always been problematic and never really used
and hence is a legacy implementation detail that needs to be supported
but in reality the vast majority of NEON optimisation happens at run
time in libraries where it make a difference.

In the case of the 'c' crypto extenions we have explicitly not added
this as package management functionality as it's handled effectively
with run time detection as optimisaiton and as in Fefora has just
caused regressions and issues.

Fixes RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1691430

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>

Closes: #818
Approved by: <try>
@dmach dmach self-assigned this Oct 18, 2019
@rh-atomic-bot
Copy link

💔 Test failed - status-papr

@dmach
Copy link

dmach commented Nov 22, 2019

Merging manually as the automated test failed.

@dmach dmach merged commit f1f5830 into rpm-software-management:master Nov 22, 2019
@nullr0ute
Copy link
Contributor Author

Thanks @dmach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants