Buildresult: powerpc-next/ppc64e_defconfig+UP/powerpc-gcc5 built on Jul 24 2020, 04:47

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Jul 24 2020, 04:47
Duration:	0:02:06.057806
Builder:	ka1
Revision:	Merge branch 'scv' support into next (`335aca5f65f1a39670944930131da5f2276f888f)`
Target:	powerpc-next/ppc64e_defconfig+UP/powerpc-gcc5
Branch:	powerpc-next
Compiler:	powerpc-gcc5 (powerpc64-linux-gcc (GCC) 5.5.0 / GNU ld (GNU Binutils) 2.29.1.20170915)
Config:	ppc64e_defconfig+UP (download)
Log:	Download original Possible warnings (2) warning: The last gc run reported the following. Please correct the root cause warning: There are too many unreachable loose objects; run 'git prune' to remove them. Full Log # git rev-parse -q --verify 335aca5f65f1a39670944930131da5f2276f888f^{commit} # git fetch -q -n -f git://gitlab.ozlabs.ibm.com/linuxppc/linux.git next-test warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. # git rev-parse -q --verify 335aca5f65f1a39670944930131da5f2276f888f^{commit} 335aca5f65f1a39670944930131da5f2276f888f # git checkout -q -f -B kisskb 335aca5f65f1a39670944930131da5f2276f888f # git clean -qxdf # < git log -1 # commit 335aca5f65f1a39670944930131da5f2276f888f # Merge: 8ac9b9d61f0e 7fa95f9adaee # Author: Michael Ellerman <mpe@ellerman.id.au> # Date: Thu Jul 23 17:43:44 2020 +1000 # # Merge branch 'scv' support into next # # From Nick's cover letter: # # Linux powerpc new system call instruction and ABI # # System Call Vectored (scv) ABI # ============================== # # The scv instruction is introduced with POWER9 / ISA3, it comes with an # rfscv counter-part. The benefit of these instructions is # performance (trading slower SRR0/1 with faster LR/CTR registers, and # entering the kernel with MSR[EE] and MSR[RI] left enabled, which can # reduce MSR updates. The scv instruction has 128 levels (not enough to # cover the Linux system call space). # # Assignment and advertisement # ---------------------------- # The proposal is to assign scv levels conservatively, and advertise # them with HWCAP feature bits as we add support for more. # # Linux has not enabled FSCR[SCV] yet, so executing the scv instruction # will cause the kernel to log a "SCV facility unavilable" message, and # deliver a SIGILL with ILL_ILLOPC to the process. Linux has defined a # HWCAP2 bit PPC_FEATURE2_SCV for SCV support, but does not set it. # # This change allocates the zero level ('scv 0'), advertised with # PPC_FEATURE2_SCV, which will be used to provide normal Linux system # calls (equivalent to 'sc'). # # Attempting to execute scv with other levels will cause a SIGILL to be # delivered the same as before, but will not log a "SCV facility # unavailable" message (because the processor facility is enabled). # # Calling convention # ------------------ # The proposal is for scv 0 to provide the standard Linux system call # ABI with the following differences from sc convention[1]: # # - LR is to be volatile across scv calls. This is necessary because the # scv instruction clobbers LR. From previous discussion, this should # be possible to deal with in GCC clobbers and CFI. # # - cr1 and cr5-cr7 are volatile. This matches the C ABI and would allow # the kernel system call exit to avoid restoring the volatile cr # registers (although we probably still would anyway to avoid # information leaks). # # - Error handling: The consensus among kernel, glibc, and musl is to # move to using negative return values in r3 rather than CR0[SO]=1 to # indicate error, which matches most other architectures, and is # closer to a function call. # # Notes # ----- # - r0,r4-r8 are documented as volatile in the ABI, but the kernel patch # as submitted currently preserves them. This is to leave room for # deciding which way to go with these. Some small benefit was found by # preserving them[1] but I'm not convinced it's worth deviating from # the C function call ABI just for this. Release code should follow # the ABI. # # Previous discussions: # https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208691.html # https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/209268.html # # [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst # [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/209263.html # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld --version # < git log --format=%s --max-count=1 335aca5f65f1a39670944930131da5f2276f888f # < make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64e_defconfig+UP_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ppc64e_defconfig # Added to kconfig CONFIG_SMP=n # < make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64e_defconfig+UP_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- help # make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64e_defconfig+UP_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- olddefconfig # make -s -j 48 ARCH=powerpc O=/kisskb/build/powerpc-next_ppc64e_defconfig+UP_powerpc-gcc5 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-5.5.0-nolibc/powerpc64-linux/bin/powerpc64-linux- INFO: Uncompressed kernel (size 0xb84c38) overlaps the address of the wrapper(0x400000) INFO: Fixing the link_address of wrapper to (0xc00000) Image Name: Linux-5.8.0-rc2-g335aca5f65f1 Created: Fri Jul 24 04:49:22 2020 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 4807356 Bytes = 4694.68 KiB = 4.58 MiB Load Address: 00000000 Entry Point: 00000000 Completed OK # rm -rf /kisskb/build/powerpc-next_ppc64e_defconfig+UP_powerpc-gcc5 # Build took: 0:02:06.057806

© Michael Ellerman 2006-2018.