Bug 1425007 - RFE: add ppc architecture support
Summary: RFE: add ppc architecture support
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libseccomp
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Paul Moore
QA Contact: Virtualization Bugs
Ioanna Gkioka
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: tracker-rebase 1391018
TreeView+ depends on / blocked
 
Reported: 2017-02-20 11:17 UTC by Kalev Lember
Modified: 2019-06-10 09:29 UTC (History)
7 users (show)

(edit)
*libseccomp* now supports IBM Power architectures

With this update, the *libseccomp* library supports the IBM Power, 64-bit IBM Power, and 64-bit little-endian IBM Power architectures, which enables the GNOME rebase.
Clone Of:
(edit)
Last Closed: 2017-08-01 12:39:45 UTC


Attachments (Terms of Use)
Regression live test result (4.54 KB, text/plain)
2017-06-02 09:48 UTC, Zhengtong
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:2165 normal SHIPPED_LIVE libseccomp enhancement update 2017-08-01 16:08:45 UTC

Description Kalev Lember 2017-02-20 11:17:22 UTC
We're working on a desktop rebase in RHEL 7.4. Various packages, such as flatpak and tracker now depend on libseccomp. However, libseccomp is currently missing on the ppc architecture, which makes it difficult to rebase GNOME as we would have to ExcludeArch a large part of it.

A quick brew scratch build that has ExcludeArch taken out indicates that libseccomp builds just fine on the ppc arch:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=12576224

Please remove the ExcludeArch (or add ppc to it) and rebuild libseccomp for RHEL 7.4.

Comment 2 Paul Moore 2017-02-20 15:19:07 UTC
The upstream libseccomp project has supported ppc, ppc64, and ppc64le since libseccomp v2.3.0 which was released on February 29th, 2016.  Enabling support for RHEL-7.x is more of a business decision than a technical hurdle (as you found out be removing the build restriction).

I'm setting the devel_ack flag, and I'm going to ping PM/management to see what needs to be done.  If you can escalate this on your end to get the necessary approvals that would be helpful too.

* https://github.com/seccomp/libseccomp/releases/tag/v2.3.0

Comment 3 Kalev Lember 2017-02-20 17:43:02 UTC
Excellent, thanks! mclasen said he'd bring this up at a meeting with pm on Wednesday.

Comment 4 Qunfang Zhang 2017-02-21 06:04:33 UTC
(In reply to Paul Moore from comment #2)
> The upstream libseccomp project has supported ppc, ppc64, and ppc64le since
> libseccomp v2.3.0 which was released on February 29th, 2016.  Enabling
> support for RHEL-7.x is more of a business decision than a technical hurdle
> (as you found out be removing the build restriction).
> 
> I'm setting the devel_ack flag, and I'm going to ping PM/management to see
> what needs to be done.  If you can escalate this on your end to get the
> necessary approvals that would be helpful too.
> 
> * https://github.com/seccomp/libseccomp/releases/tag/v2.3.0

Hi, Paul

Could I know what testing need to be done for virt for the ppc arch? Since currently only ppc64 (guest side) and ppc64le (host and guest) will be covered for kvm feature testing.  Thanks!

Comment 5 Paul Moore 2017-02-21 13:46:35 UTC
Hello,

Unfortunately I don't know how libseccomp is tested here inside RH.  To be honest the testing responsibilities probably shouldn't reside solely with the virt team as libseccomp now has a number of users beyond virtualization, flatpack is just one example.

Upstream we have a bundled test suite with both simulated and live tests (see the "tests" directory) and we've recently added Travis CI builds that execute the test suite as well as the clang and Coverity static analyzers.

I'm sorry this probably doesn't answer your question very well ...

Comment 6 Qunfang Zhang 2017-02-22 03:10:55 UTC
Hi, Paul

Thanks for your explanation, I would ack this bug now and will do the following test as verification result:
(1) check whether the expected build appears in brewweb.
(2) make sure it's included in the install tree.

So, if this is not enough pls help inform related team for extra testing. It sounds great for the test suite in Travis CI builds.

Comment 7 Paul Moore 2017-02-22 13:48:07 UTC
(In reply to Qunfang Zhang from comment #6)
> Hi, Paul
> 
> Thanks for your explanation, I would ack this bug now and will do the
> following test as verification result:
> (1) check whether the expected build appears in brewweb.
> (2) make sure it's included in the install tree.
> 
> So, if this is not enough pls help inform related team for extra testing. It
> sounds great for the test suite in Travis CI builds.

While we run the simulated tests as part of the RPM build process, we don't run the "live" tests for a variety of reasons.  If you have the time, it might be helpful to download the associated release tarball from upstream and verify the live tests on a ppc64/ppc64le system.  You can do that with the following commands (assuming you have downloaded and unpacked the tarball already):

  # ./configure
  # make check-build
  # cd tests
  # ./regression -T live

If you have any questions, let me know.

Comment 15 Zhengtong 2017-06-02 09:46:56 UTC
Hi Paul,

A. We have done sandybox(syscall filter) testing with package libseccomp-2.3.1-3.el7.ppc64le.rpm installed in host(has been added to compose). No regression bug found. So I think it's ok for virt side.

B. I did  regression live test with our internal package. steps and results are as follows:
  step1: wget libseccomp-2.3.1-3.el7.src.rpm from our brew web.
  step2: # rpm2cpio libseccomp-2.3.1-3.el7.src.rpm | cpio -div
  step3: unzip the tar file generated in step2
         #tar -zxvf libseccomp-2.3.1.tar.gz
  step4: #cd libseccomp-2.3.1
  step5: #./configure; make check-build
  step6: #cd tests
  step7: #./regression -T live
1 of 6 runs tested failed, 5 others passed. I will attach the full result.

I am not sure whether the failed cases matter so much or not.
what's your opinion, Paul? If that does not matter or be expected. I will set the bug verified.

I tried with uptream package. got the same result.

Comment 16 Zhengtong 2017-06-02 09:48 UTC
Created attachment 1284371 [details]
Regression live test result

Comment 17 Paul Moore 2017-06-02 12:49:24 UTC
Hi Zhengtong,

That single failure is expected on RHEL-7.x since the current RHEL-7.x kernels do not currently support the SECCOMP_FILTER_FLAG_TSYNC functionality.  This is a kernel issue and not a libseccomp issue.

Comment 18 Paul Moore 2017-06-02 12:56:27 UTC
I went ahead and created a RFE BZ for the seccomp-bpf TSYNC functionality:

* https://bugzilla.redhat.com/show_bug.cgi?id=1458278

Comment 19 Zhengtong 2017-06-05 02:17:20 UTC
Thanks Paul. then verified the bug.

Comment 20 errata-xmlrpc 2017-08-01 12:39:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2165


Note You need to log in before you can comment on or make changes to this bug.