[powerpc:next] BUILD SUCCESS ac2a2303016baed1a60343500e265519cc45e4d2
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: ac2a2303016baed1a60343500e265519cc45e4d2 Merge branch 'topic/ppc-kvm' into next elapsed time: 721m configs tested: 69 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm64allyesconfig arm defconfig arm allyesconfig i386 randconfig-c001 sh polaris_defconfig i386defconfig powerpc asp8347_defconfig arc defconfig nios2 defconfig s390 debug_defconfig arm64 defconfig m68k allyesconfig powerpc ppc64_defconfig arm lpc18xx_defconfig m68km5407c3_defconfig mipsbcm47xx_defconfig sh shx3_defconfig mips fuloong2e_defconfig ia64 allmodconfig m68k allmodconfig arc allyesconfig alphaallyesconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig i386 allyesconfig x86_64randconfig-a006 i386 randconfig-a001 i386 randconfig-a003 i386 randconfig-a005 x86_64randconfig-a004 x86_64randconfig-a002 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 i386 randconfig-a014 i386 randconfig-a012 i386 randconfig-a016 arc randconfig-r043-20220707 riscvrandconfig-r042-20220707 s390 randconfig-r044-20220707 s390 randconfig-r044-20220710 riscvrandconfig-r042-20220710 arc randconfig-r043-20220710 um i386_defconfig um x86_64_defconfig x86_64 rhel-8.3-func x86_64 rhel-8.3-kunit x86_64 rhel-8.3-syz x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 clang tested configs: x86_64randconfig-k001 i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a001 x86_64randconfig-a003 x86_64randconfig-a005 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 i386 randconfig-a013 i386 randconfig-a015 i386 randconfig-a011 hexagon randconfig-r045-20220707 hexagon randconfig-r041-20220707 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:merge] BUILD SUCCESS ca79dc6117a73fd9c2076a404befbe917a46c5f5
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: ca79dc6117a73fd9c2076a404befbe917a46c5f5 Automatic merge of 'next' into merge (2022-07-09 20:19) elapsed time: 721m configs tested: 52 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm allyesconfig ia64 allmodconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig alphaallyesconfig m68k allmodconfig arc allyesconfig m68k allyesconfig i386defconfig i386 allyesconfig i386 randconfig-a001 i386 randconfig-a003 i386 randconfig-a005 x86_64randconfig-a015 x86_64randconfig-a013 x86_64randconfig-a011 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 arc randconfig-r043-20220707 s390 randconfig-r044-20220707 riscvrandconfig-r042-20220707 x86_64randconfig-a002 x86_64randconfig-a006 x86_64randconfig-a004 um i386_defconfig um x86_64_defconfig x86_64 defconfig x86_64 rhel-8.3 x86_64 allyesconfig x86_64 rhel-8.3-func x86_64 rhel-8.3-kunit x86_64 rhel-8.3-syz x86_64rhel-8.3-kselftests clang tested configs: i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a014 x86_64randconfig-a016 x86_64randconfig-a012 i386 randconfig-a013 i386 randconfig-a011 i386 randconfig-a015 hexagon randconfig-r045-20220707 hexagon randconfig-r041-20220707 x86_64randconfig-a005 x86_64randconfig-a001 x86_64randconfig-a003 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.19-5 tag
The pull request you sent on Sat, 09 Jul 2022 20:27:31 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.19-5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d9cdc3b12525c85b4a2a8b6f3f8f61d9f467ab9a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH] KVM: PPC: Book3S HV: Use the bitmap API to allocate bitmaps
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.
It is less verbose and it improves the semantic.
Signed-off-by: Christophe JAILLET
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 598006301620..95de5fac6497 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -1187,8 +1187,7 @@ int kvmppc_uvmem_init(void)
pfn_first = res->start >> PAGE_SHIFT;
pfn_last = pfn_first + (resource_size(res) >> PAGE_SHIFT);
- kvmppc_uvmem_bitmap = kcalloc(BITS_TO_LONGS(pfn_last - pfn_first),
- sizeof(unsigned long), GFP_KERNEL);
+ kvmppc_uvmem_bitmap = bitmap_zalloc(pfn_last - pfn_first, GFP_KERNEL);
if (!kvmppc_uvmem_bitmap) {
ret = -ENOMEM;
goto out_unmap;
@@ -1212,5 +1211,5 @@ void kvmppc_uvmem_free(void)
memunmap_pages(_uvmem_pgmap);
release_mem_region(kvmppc_uvmem_pgmap.range.start,
range_len(_uvmem_pgmap.range));
- kfree(kvmppc_uvmem_bitmap);
+ bitmap_free(kvmppc_uvmem_bitmap);
}
--
2.34.1
[PATCH] powerpc/85xx: Fix description of MPC85xx and P1/P2 boards options
More MPC85xx and P1/P2 boards options have incorrect description. Fix them to include list of all boards for which they enable/disable support. Signed-off-by: Pali Rohár --- arch/powerpc/platforms/85xx/Kconfig | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 2be17ffe8714..be16eba0f704 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -62,13 +62,13 @@ config MPC85xx_CDS This option enables support for the MPC85xx CDS board config MPC85xx_MDS - bool "Freescale MPC85xx MDS" + bool "Freescale MPC8568 MDS / MPC8569 MDS / P1021 MDS" select DEFAULT_UIMAGE select PHYLIB if NETDEVICES select HAVE_RAPIDIO select SWIOTLB help - This option enables support for the MPC85xx MDS board + This option enables support for the MPC8568 MDS, MPC8569 MDS and P1021 MDS boards config MPC8536_DS bool "Freescale MPC8536 DS" @@ -78,28 +78,30 @@ config MPC8536_DS This option enables support for the MPC8536 DS board config MPC85xx_DS - bool "Freescale MPC85xx DS" + bool "Freescale MPC8544 DS / MPC8572 DS / P2020 DS" select PPC_I8259 select DEFAULT_UIMAGE select FSL_ULI1575 if PCI select SWIOTLB help - This option enables support for the MPC85xx DS (MPC8544 DS) board + This option enables support for the MPC8544 DS, MPC8572 DS and P2020 DS boards config MPC85xx_RDB - bool "Freescale MPC85xx RDB" + bool "Freescale P102x MBG/UTM/RDB and P2020 RDB" select PPC_I8259 select DEFAULT_UIMAGE select FSL_ULI1575 if PCI select SWIOTLB help - This option enables support for the MPC85xx RDB (P2020 RDB) board + This option enables support for the P1020 MBG PC, P1020 UTM PC, + P1020 RDB PC, P1020 RDB PD, P1020 RDB, P1021 RDB PC, P1024 RDB, + P1025 RDB, P2020 RDB and P2020 RDB PC boards config P1010_RDB - bool "Freescale P1010RDB" + bool "Freescale P1010 RDB" select DEFAULT_UIMAGE help - This option enables support for the MPC85xx RDB (P1010 RDB) board + This option enables support for the P1010 RDB board P1010RDB contains P1010Si, which provides CPU performance up to 800 MHz and 1600 DMIPS, additional functionality and faster interfaces -- 2.20.1
[GIT PULL] Please pull powerpc/linux.git powerpc-5.19-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull another powerpc fix for 5.19: The following changes since commit ac790d09885d36143076e7e02825c541e8eee899: powerpc/memhotplug: Add add_pages override for PPC (2022-06-29 20:43:16 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.19-5 for you to fetch changes up to 887502826549caa7e4215fd9e628f48f14c0825a: powerpc/powernv: delay rng platform device creation until later in boot (2022-07-04 21:11:47 +1000) - -- powerpc fixes for 5.19 #5 - On Power8 bare metal, fix creation of RNG platform devices, which are needed for the /dev/hwrng driver to probe correctly. Thanks to: Jason A. Donenfeld, Sachin Sant. - -- Jason A. Donenfeld (1): powerpc/powernv: delay rng platform device creation until later in boot arch/powerpc/platforms/powernv/rng.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmLJV5YACgkQUevqPMjh pYDt0A/+LXncrh6Vivnm7RXfvjmkoEZL/mry68cCmwYxPhN0NH4wfCsMWhcUeheh ZXLeV6J42e9JwO+v1b3ENQuBjoiB3AR2YdzeisaSfumapfs0sDxqZnz9e4cKNb1h oEgrOKdNQ0A0+3fzC50G6o6Y4EGYCqth6JSFqPBexZV9aiO66lpObVip9U4kRWjU dfHHJ9xRSOaAvQawxBr2GTssFyOGQHUyKGS2bqGradSGEv754bRB0Lu34hJ/NddA aKjPzclZu1QROKQzqQiQNF0q9n8Ac9xPsrv701gXcnb0EqhSFxn8pxoavXF9SgRF OvPUmjJQbPgpVG0ltsxvcwHkAn5MdAdNLtH2gkI0ikqMjOzp7MmY90VqPgFwnfYs M/RBNhwElpeUwxJ227mT73Nykr3PZJy7ht5G3jo8ngXa6JeCQSv6W9bpQcA9mqZa MJza02CMsXysP/hHcsStJN8IIHKyfqNcKcsqwR2ZAFrgP02rhLUFRd8YO/GbE8aP aV4rEJ++71FUEy5GRMJYEdChvdPGO4qW3nMyjZz5JRKv5oxjidyXPM6bxUNV0BSy PHGiC1Ig6Ty+InsrYrzGyfsbvMwMO9dYvQtJ2HTV+yNafpRTKrG21J85ApRmM/lI r2X5HWAIyWUrzNMIvC9ddhkfEx3hPHdRDJT8WlYnIZicM4Vucqw= =1BAn -END PGP SIGNATURE-
Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler
On Saturday 09 July 2022 09:16:13 Christophe Leroy wrote:
> Le 08/07/2022 à 19:14, Pali Rohár a écrit :
> > On Monday 04 July 2022 15:13:58 Pali Rohár wrote:
> >> On Monday 04 July 2022 14:07:10 Arnd Bergmann wrote:
> >>> On Mon, Jul 4, 2022 at 12:39 PM Pali Rohár wrote:
> On Monday 04 July 2022 20:23:29 Michael Ellerman wrote:
> > On 2 July 2022 7:44:05 pm AEST, "Pali Rohár" wrote:
> >> On Tuesday 24 May 2022 11:39:39 Pali Rohár wrote:
> >>> gcc e500 compiler does not support -mcpu=powerpc option. When it is
> >>> specified then gcc throws compile error:
> >>>
> >>>gcc: error: unrecognized argument in option ‘-mcpu=powerpc’
> >>>gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native
> >>>
> >>> So do not set -mcpu=powerpc option when CONFIG_E500 is set. Correct
> >>> option
> >>> -mcpu=8540 for CONFIG_E500 is set few lines below in that Makefile.
> >>>
> >>> Signed-off-by: Pali Rohár
> >>> Cc: sta...@vger.kernel.org
> >>
> >> Michael, do you have any objections about this patch?
> >
> > I don't particularly like it :)
> >
> > From the discussion with Segher, it sounds like this is a problem with
> > a specific build of gcc that you're using, not a general problem with
> > gcc built with e500 support.
>
> Well, the "full" build of gcc for e500 cores with SPE does not support
> -mcpu=powerpc option. So I think this is a general problem. I do not
> think that this is "specific build" as this is the correct build of gcc
> for these processors with e500 cores.
>
> "stripped". build of gcc without SPE support for e500 cores does not
> have this problem...
> >>>
> >>> I can see a couple of problems with the CPU selection, but I don't think
> >>> this is a major one, as nobody should be using those SPE compilers for
> >>> building the kernel. Just use a modern powerpc-gcc build.
> >>
> >> The point is to use same compiler for building kernel as for the all
> >> other parts of the system.
> >>
> >> I just do not see reason why for kernel it is needed to build completely
> >> different toolchain and compiler.
> >>
> > Keying it off CONFIG_E500 means it will fix your problem, but not
> > anyone else who has a different non-e500 compiler that also doesn't
> > support -mcpu=powerpc (for whatever reason).
> >
> > So I wonder if a better fix is to use cc-option when setting
> > -mcpu=powerpc.
> >
>
> Comment for that code which adds -mpcu=powerpc says:
>
> they are needed to set a sane 32-bit cpu target for the 64-bit cross
> compiler which may default to the wrong ISA.
>
> So I'm not sure how to handle this in other way. GCC uses -mpcu=8540
> option for specifying to compile code for e500 cores and seems that
> -mcpu=8540 is supported by all e500 compilers...
>
> Few lines below is code
>
> CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540
> -msoft-float,-mcpu=powerpc)
>
> which for e500 kernel builds user either -mcpu=8540 or -mcpu=powerpc
> (probably as a fallback if -mcpu=8540 is not supported).
> >>>
> >>> The -mcpu=powerpc fallback can probably be skipped here, that must have
> >>> been
> >>> for compilers predating the addition of -mcpu=8540, and even the oldest
> >>> ones
> >>> support that now.
> >>
> >> Ok, makes sense.
> >>
> So for me it looks like that problematic code
>
> KBUILD_CFLAGS += -mcpu=powerpc
> KBUILD_AFLAGS += -mcpu=powerpc
>
> needs to be somehow skipped when compiling for CONFIG_E500.
> > My change which skips that code base on ifndef CONFIG_E500 should be
> fine as when CONFIG_E500 is disabled it does nothing and when it is
> enabled then code
>
> CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540
> -msoft-float,-mcpu=powerpc)
>
> is called which sets -mcpu option suitable for e500.
> >>>
> >>> I think this part is indeed fishy, but adding another special case for
> >>> E500
> >>> seems to take it in the wrong direction.
> >>>
> >>> Nick added this in 4bf4f42a2feb ("powerpc/kbuild: Set default generic
> >>> machine type
> >>> for 32-bit compile") as a compile-time fix to prevent the default target
> >>> from
> >>> getting used when the compiler supports both 64-bit and 32-bit. This is
> >>> the
> >>> right idea, but it's inconsistent to pass different flags depending on
> >>> the type
> >>> of toolchain, and it loses the more specific options.
> >>>
> >>> Another problem I see is that a kernel that is built for both E500 and
> >>> E500MC
> >>> uses -mcpu=e500mc and may not actually work on the older ones either
> >>> (even with your patch).
> >>
> >> That is probably truth, -mcpu=8540 should have been chosen. (Anyway it
> >> should have been called -mcpu=e500, no idea why gcc still name it 8540.)
> >>
> >>> I
Re: [PATCH] KVM: PPC: Kconfig: Fix indentation
On Fri, 20 May 2022 13:54:31 +0200, Juerg Haefliger wrote: > The convention for indentation seems to be a single tab. Help text is > further indented by an additional two whitespaces. Fix the lines that > violate these rules. > > Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Kconfig: Fix indentation https://git.kernel.org/powerpc/c/81e9685dd41384a39adda823df8b4f6e16ec2898 cheers
Re: [PATCH] KVM: PPC: Book3S HV: tracing: Add missing hcall names
On Tue, 14 Jun 2022 13:52:04 -0300, Fabiano Rosas wrote: > The kvm_trace_symbol_hcall macro is missing several of the hypercalls > defined in hvcall.h. > > Add the most common ones that are issued during guest lifetime, > including the ones that are only used by QEMU and SLOF. > > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Book3S HV: tracing: Add missing hcall names https://git.kernel.org/powerpc/c/0df01238b8aa300cbc736e7ec433d201a76036f3 cheers
Re: [PATCH v2] KVM: PPC: Align pt_regs in kvm_vcpu_arch structure
On Fri, 24 Jun 2022 11:27:12 -0300, Fabiano Rosas wrote: > The H_ENTER_NESTED hypercall receives as second parameter the address > of a region of memory containing the values for the nested guest > privileged registers. We currently use the pt_regs structure contained > within kvm_vcpu_arch for that end. > > Most hypercalls that receive a memory address expect that region to > not cross a 4K page boundary. We would want H_ENTER_NESTED to follow > the same pattern so this patch ensures the pt_regs structure sits > within a page. > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Align pt_regs in kvm_vcpu_arch structure https://git.kernel.org/powerpc/c/f5c847ea19d323974d6f7c7e9fa4858ce0727096 cheers
Re: [PATCH 0/5] KVM: PPC: Book3S HV: Update debug timing code
On Wed, 25 May 2022 10:05:49 -0300, Fabiano Rosas wrote: > We have some debug information at /sys/kernel/debug/kvm//vcpu#/timings > which shows the time it takes to run various parts of the code. > > That infrastructure was written in the P8 timeframe and wasn't updated > along with the guest entry point changes for P9. > > Ideally we would be able to just add new/different accounting points > to the code as it changes over time but since the P8 and P9 entry > points are different code paths we first need to separate them from > each other. This series alters KVM Kconfig to make that distinction. > > [...] Applied to powerpc/topic/ppc-kvm. [1/5] KVM: PPC: Book3S HV: Fix "rm_exit" entry in debugfs timings https://git.kernel.org/powerpc/c/9981bace85d816ed8724ac46e49285e8488d29e6 [2/5] KVM: PPC: Book3S HV: Add a new config for P8 debug timing https://git.kernel.org/powerpc/c/3f8ed993be3cf154a91d9ab5e80470c6c755adbe [3/5] KVM: PPC: Book3S HV: Decouple the debug timing from the P8 entry path https://git.kernel.org/powerpc/c/c3fa64c99c61d99631a8e06a6cf991c35c98ec7d [4/5] KVM: PPC: Book3S HV: Expose timing functions to module code https://git.kernel.org/powerpc/c/2861c827286fb6646f6b6caee418efd2097c [5/5] KVM: PPC: Book3S HV: Provide more detailed timings for P9 entry path https://git.kernel.org/powerpc/c/b44bb1b7cbbae66ec73868f5fbd57c54f0612d1c cheers
Re: [PATCH kernel] KVM: PPC: Do not warn when userspace asked for too big TCE table
On Tue, 28 Jun 2022 18:02:28 +1000, Alexey Kardashevskiy wrote: > KVM manages emulated TCE tables for guest LIOBNs by a two level table > which maps up to 128TiB with 16MB IOMMU pages (enabled in QEMU by default) > and MAX_ORDER=11 (the kernel's default). Note that the last level of > the table is allocated when actual TCE is updated. > > However these tables are created via ioctl() on kvmfd and the userspace > can trigger WARN_ON_ONCE_GFP(order >= MAX_ORDER, gfp) in mm/page_alloc.c > and flood dmesg. > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Do not warn when userspace asked for too big TCE table https://git.kernel.org/powerpc/c/4dee21e0f2520f5032b0abce0ecae593a71bd19d cheers
Re: [PATCH kernel] KVM: PPC: Book3s: Fix warning about xics_rm_h_xirr_x
On Wed, 22 Jun 2022 15:52:35 +1000, Alexey Kardashevskiy wrote: > This fixes "no previous prototype": > > arch/powerpc/kvm/book3s_hv_rm_xics.c:482:15: > warning: no previous prototype for 'xics_rm_h_xirr_x' [-Wmissing-prototypes] > > Reported by the kernel test robot. > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Book3s: Fix warning about xics_rm_h_xirr_x https://git.kernel.org/powerpc/c/a784101f77b1bef4b40f4ad68af3f54fcfa5321b cheers
Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler
Le 08/07/2022 à 22:04, Arnd Bergmann a écrit :
> On Fri, Jul 8, 2022 at 7:12 PM Pali Rohár wrote:
>>
>> On Monday 04 July 2022 14:07:10 Arnd Bergmann wrote:
>>> Another problem I see is that a kernel that is built for both E500 and
>>> E500MC
>>> uses -mcpu=e500mc and may not actually work on the older ones either
>>> (even with your patch).
>>
>> Such configuration is not supported, see
>> arch/powerpc/platforms/Kconfig.cputype:
>>
>> config PPC_E500MC
>> bool "e500mc Support"
>> select PPC_FPU
>> select COMMON_CLK
>> depends on E500
>> help
>>This must be enabled for running on e500mc (and derivatives
>>such as e5500/e6500), and must be disabled for running on
>>e500v1 or e500v2.
>>
>> Based on this option you can enable either support for e500v1/e500v2 or
>> for e500mc. But not both.
>
> This looks like a bad decision in Kconfig though, as there is nothing
> enforcing the rule: If you want support for E500MC, you have to select
> PPC_85xx, which implies E500 and allows selecting any combination
> of E500v1, E500v2 and E500MC based machines, but enabling
> any E500MC based one breaks all the others.
>
> If this is a hard dependency, I think it should be enforced by making
> E500MC a separate top-level option in the "Processor Type" choice
> statement. However, if they can actually coexist, the help text and
> the Makefile need to be fixed.
>
While looking at this discussion, I discovered that with GCC 12 from
https://mirrors.edge.kernel.org/pub/tools/crosstool/ I'm unable to build
a corenet64_smp_defconfig:
If I select the GENERIC_CPU or e5500 (with altivec) I get:
CC arch/powerpc/kernel/irq.o
{standard input}: Assembler messages:
{standard input}:3535: Error: unrecognized opcode: `wrteei'
{standard input}:5608: Error: unrecognized opcode: `wrteei'
CC arch/powerpc/kernel/pmc.o
{standard input}: Assembler messages:
{standard input}:42: Error: unrecognized opcode: `mfpmr'
{standard input}:53: Error: unrecognized opcode: `mtpmr'
If I select the e5500 (without altivec) or e6500 I get:
CC arch/powerpc/kernel/io.o
{standard input}: Assembler messages:
{standard input}:381: Error: unrecognized opcode: `eieio'
{standard input}:444: Error: unrecognized opcode: `eieio'
{standard input}:480: Error: unrecognized opcode: `eieio'
{standard input}:506: Error: unrecognized opcode: `eieio'
{standard input}:552: Error: unrecognized opcode: `eieio'
{standard input}:817: Error: unrecognized opcode: `eieio'
{standard input}:839: Error: unrecognized opcode: `eieio'
{standard input}:885: Error: unrecognized opcode: `eieio'
{standard input}:1106: Error: unrecognized opcode: `eieio'
{standard input}:1130: Error: unrecognized opcode: `eieio'
{standard input}:1174: Error: unrecognized opcode: `eieio'
{standard input}:1393: Error: unrecognized opcode: `eieio'
{standard input}:1417: Error: unrecognized opcode: `eieio'
{standard input}:1461: Error: unrecognized opcode: `eieio'
Christophe
Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler
Le 08/07/2022 à 19:14, Pali Rohár a écrit :
> On Monday 04 July 2022 15:13:58 Pali Rohár wrote:
>> On Monday 04 July 2022 14:07:10 Arnd Bergmann wrote:
>>> On Mon, Jul 4, 2022 at 12:39 PM Pali Rohár wrote:
On Monday 04 July 2022 20:23:29 Michael Ellerman wrote:
> On 2 July 2022 7:44:05 pm AEST, "Pali Rohár" wrote:
>> On Tuesday 24 May 2022 11:39:39 Pali Rohár wrote:
>>> gcc e500 compiler does not support -mcpu=powerpc option. When it is
>>> specified then gcc throws compile error:
>>>
>>>gcc: error: unrecognized argument in option ‘-mcpu=powerpc’
>>>gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native
>>>
>>> So do not set -mcpu=powerpc option when CONFIG_E500 is set. Correct
>>> option
>>> -mcpu=8540 for CONFIG_E500 is set few lines below in that Makefile.
>>>
>>> Signed-off-by: Pali Rohár
>>> Cc: sta...@vger.kernel.org
>>
>> Michael, do you have any objections about this patch?
>
> I don't particularly like it :)
>
> From the discussion with Segher, it sounds like this is a problem with a
> specific build of gcc that you're using, not a general problem with gcc
> built with e500 support.
Well, the "full" build of gcc for e500 cores with SPE does not support
-mcpu=powerpc option. So I think this is a general problem. I do not
think that this is "specific build" as this is the correct build of gcc
for these processors with e500 cores.
"stripped". build of gcc without SPE support for e500 cores does not
have this problem...
>>>
>>> I can see a couple of problems with the CPU selection, but I don't think
>>> this is a major one, as nobody should be using those SPE compilers for
>>> building the kernel. Just use a modern powerpc-gcc build.
>>
>> The point is to use same compiler for building kernel as for the all
>> other parts of the system.
>>
>> I just do not see reason why for kernel it is needed to build completely
>> different toolchain and compiler.
>>
> Keying it off CONFIG_E500 means it will fix your problem, but not anyone
> else who has a different non-e500 compiler that also doesn't support
> -mcpu=powerpc (for whatever reason).
>
> So I wonder if a better fix is to use cc-option when setting
> -mcpu=powerpc.
>
Comment for that code which adds -mpcu=powerpc says:
they are needed to set a sane 32-bit cpu target for the 64-bit cross
compiler which may default to the wrong ISA.
So I'm not sure how to handle this in other way. GCC uses -mpcu=8540
option for specifying to compile code for e500 cores and seems that
-mcpu=8540 is supported by all e500 compilers...
Few lines below is code
CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540
-msoft-float,-mcpu=powerpc)
which for e500 kernel builds user either -mcpu=8540 or -mcpu=powerpc
(probably as a fallback if -mcpu=8540 is not supported).
>>>
>>> The -mcpu=powerpc fallback can probably be skipped here, that must have been
>>> for compilers predating the addition of -mcpu=8540, and even the oldest ones
>>> support that now.
>>
>> Ok, makes sense.
>>
So for me it looks like that problematic code
KBUILD_CFLAGS += -mcpu=powerpc
KBUILD_AFLAGS += -mcpu=powerpc
needs to be somehow skipped when compiling for CONFIG_E500.
> My change which skips that code base on ifndef CONFIG_E500 should be
fine as when CONFIG_E500 is disabled it does nothing and when it is
enabled then code
CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540
-msoft-float,-mcpu=powerpc)
is called which sets -mcpu option suitable for e500.
>>>
>>> I think this part is indeed fishy, but adding another special case for E500
>>> seems to take it in the wrong direction.
>>>
>>> Nick added this in 4bf4f42a2feb ("powerpc/kbuild: Set default generic
>>> machine type
>>> for 32-bit compile") as a compile-time fix to prevent the default target
>>> from
>>> getting used when the compiler supports both 64-bit and 32-bit. This is the
>>> right idea, but it's inconsistent to pass different flags depending on the
>>> type
>>> of toolchain, and it loses the more specific options.
>>>
>>> Another problem I see is that a kernel that is built for both E500 and
>>> E500MC
>>> uses -mcpu=e500mc and may not actually work on the older ones either
>>> (even with your patch).
>>
>> That is probably truth, -mcpu=8540 should have been chosen. (Anyway it
>> should have been called -mcpu=e500, no idea why gcc still name it 8540.)
>>
>>> I think what you actually want is to set one option for each of the
>>> possible CPU types:
>>>
>>> CFLAGS_CPU-$(CONFIG_PPC_BOOK3S_32) := -mcpu=powerpc
>>> CFLAGS_CPU-$(CONFIG_PPC_85xx) := -mcpu=8540
>>> CFLAGS_CPU-$(CONFIG_PPC8xx) := -mcpu=860
>>> CFLAGS_CPU-$(CONFIG_PPC44x) := -mcpu=440
>>>
Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler
Le 08/07/2022 à 22:04, Arnd Bergmann a écrit :
> On Fri, Jul 8, 2022 at 7:12 PM Pali Rohár wrote:
>>
>> On Monday 04 July 2022 14:07:10 Arnd Bergmann wrote:
>>> Another problem I see is that a kernel that is built for both E500 and
>>> E500MC
>>> uses -mcpu=e500mc and may not actually work on the older ones either
>>> (even with your patch).
>>
>> Such configuration is not supported, see
>> arch/powerpc/platforms/Kconfig.cputype:
>>
>> config PPC_E500MC
>> bool "e500mc Support"
>> select PPC_FPU
>> select COMMON_CLK
>> depends on E500
>> help
>>This must be enabled for running on e500mc (and derivatives
>>such as e5500/e6500), and must be disabled for running on
>>e500v1 or e500v2.
>>
>> Based on this option you can enable either support for e500v1/e500v2 or
>> for e500mc. But not both.
>
> This looks like a bad decision in Kconfig though, as there is nothing
> enforcing the rule: If you want support for E500MC, you have to select
> PPC_85xx, which implies E500 and allows selecting any combination
> of E500v1, E500v2 and E500MC based machines, but enabling
> any E500MC based one breaks all the others.
>
> If this is a hard dependency, I think it should be enforced by making
> E500MC a separate top-level option in the "Processor Type" choice
> statement. However, if they can actually coexist, the help text and
> the Makefile need to be fixed.
>
In cputable.c you have entries in the cpu_specs table. It show that when
selecting PPC32 and E500MC, you exclude e500 and e500v2, allthough you
then fallback on the generic e500 probably by mistake.
Seems to come from commit 3477e71d5319 ("powerpc/booke: Restrict SPE
exception handlers to e200/e500 cores"), before that we had both e500
and e500mc in the table at the same time.
But when e500mc was introduced by commit 3dfa8773674e ("powerpc/booke:
Add support for new e500mc core"), it was already clear that it was not
compatible with other e500, especially due to the size of the cacheline,
which is hardcoded at buildtime on PPC32.
The comment in Kconfig.cputype was added my commit 9653018b615b
("powerpc/e500: add paravirt QEMU platform")
And by the way, today you are able to build a kernel with an empty
cpu_specs[] table if you select CONFIG_PPC_BOOK3E_64 and select neither
CONFIG_CORENET_GENERIC nor CONFIG_PPC_QEMU_E500
static struct cpu_spec __initdata cpu_specs[] = {
#ifdef CONFIG_E500
#ifdef CONFIG_PPC32
#ifndef CONFIG_PPC_E500MC
{ /* e500 */
.pvr_mask = 0x,
.pvr_value = 0x8020,
.cpu_name = "e500",
.cpu_features = CPU_FTRS_E500,
},
{ /* e500v2 */
.pvr_mask = 0x,
.pvr_value = 0x8021,
.cpu_name = "e500v2",
.cpu_features = CPU_FTRS_E500_2,
},
#else
{ /* e500mc */
.pvr_mask = 0x,
.pvr_value = 0x8023,
.cpu_name = "e500mc",
.cpu_features = CPU_FTRS_E500MC,
},
#endif /* CONFIG_PPC_E500MC */
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC_E500MC
{ /* e5500 */
.pvr_mask = 0x,
.pvr_value = 0x8024,
.cpu_name = "e5500",
.cpu_features = CPU_FTRS_E5500,
},
{ /* e6500 */
.pvr_mask = 0x,
.pvr_value = 0x8040,
.cpu_name = "e6500",
.cpu_features = CPU_FTRS_E6500,
},
#endif /* CONFIG_PPC_E500MC */
#ifdef CONFIG_PPC32
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
.cpu_name = "(generic E500 PPC)",
.cpu_features = CPU_FTRS_E500,
}
#endif /* CONFIG_PPC32 */
Re: [PATCH v2 0/7] Implement inline static calls on PPC32 - v2
Hello Christophe, On Fri, 8 Jul 2022 at 19:32, Christophe Leroy wrote: > > This series applies on top of the series v3 "objtool: Enable and > implement --mcount option on powerpc" [1] rebased on powerpc-next branch > > A few modifications are done to core parts to enable powerpc > implementation: > - R_X86_64_PC32 is abstracted to R_REL32 so that it can then be > redefined as R_PPC_REL32. > - A call to static_call_init() is added to start_kernel() to avoid > every architecture to have to call it > - Trampoline address is provided to arch_static_call_transform() even > when setting a site to fallback on a call to the trampoline when the > target is too far. > > [1] > https://lore.kernel.org/lkml/70b6d08d-aced-7f4e-b958-a3c7ae1a9...@csgroup.eu/T/#rb3a073c54aba563a135fba891e0c34c46e47beef > > Christophe Leroy (7): > powerpc: Add missing asm/asm.h for objtool > objtool/powerpc: Activate objtool on PPC32 > objtool: Add architecture specific R_REL32 macro > objtool/powerpc: Add necessary support for inline static calls > init: Call static_call_init() from start_kernel() > static_call_inline: Provide trampoline address when updating sites > powerpc/static_call: Implement inline static calls > Could you quantify the performance gains of moving from out-of-line, patched tail-call branch instructions to full-fledged inline static calls? On x86, the retpoline problem makes this glaringly obvious, but on other architectures, the complexity of supporting this model may outweigh the performance advantages.
