Re: [PATCH 1/4] KVM: delete .change_pte MMU notifier callback
Paolo Bonzini writes:
> The .change_pte() MMU notifier callback was intended as an
> optimization. The original point of it was that KSM could tell KVM to flip
> its secondary PTE to a new location without having to first zap it. At
> the time there was also an .invalidate_page() callback; both of them were
> *not* bracketed by calls to mmu_notifier_invalidate_range_{start,end}(),
> and .invalidate_page() also doubled as a fallback implementation of
> .change_pte().
>
> Later on, however, both callbacks were changed to occur within an
> invalidate_range_start/end() block.
>
> In the case of .change_pte(), commit 6bdb913f0a70 ("mm: wrap calls to
> set_pte_at_notify with invalidate_range_start and invalidate_range_end",
> 2012-10-09) did so to remove the fallback from .invalidate_page() to
> .change_pte() and allow sleepable .invalidate_page() hooks.
>
> This however made KVM's usage of the .change_pte() callback completely
> moot, because KVM unmaps the sPTEs during .invalidate_range_start()
> and therefore .change_pte() has no hope of finding a sPTE to change.
> Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
> well as all the architecture specific implementations.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/arm64/kvm/mmu.c | 34 -
> arch/loongarch/include/asm/kvm_host.h | 1 -
> arch/loongarch/kvm/mmu.c | 32
> arch/mips/kvm/mmu.c | 30 ---
> arch/powerpc/include/asm/kvm_ppc.h| 1 -
> arch/powerpc/kvm/book3s.c | 5 ---
> arch/powerpc/kvm/book3s.h | 1 -
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 12 --
> arch/powerpc/kvm/book3s_hv.c | 1 -
> arch/powerpc/kvm/book3s_pr.c | 7
> arch/powerpc/kvm/e500_mmu_host.c | 6 ---
LGTM.
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH 1/3] init: Declare rodata_enabled and mark_rodata_ro() at all time
Cc +Kees
Christophe Leroy writes:
> Declaring rodata_enabled and mark_rodata_ro() at all time
> helps removing related #ifdefery in C files.
>
> Signed-off-by: Christophe Leroy
> ---
> include/linux/init.h | 4
> init/main.c | 21 +++--
> 2 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 01b52c9c7526..d2b47be38a07 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -168,12 +168,8 @@ extern initcall_entry_t __initcall_end[];
>
> extern struct file_system_type rootfs_fs_type;
>
> -#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
> extern bool rodata_enabled;
> -#endif
> -#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void);
> -#endif
>
> extern void (*late_time_init)(void);
>
> diff --git a/init/main.c b/init/main.c
> index e24b0780fdff..807df08c501f 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1396,10 +1396,9 @@ static int __init set_debug_rodata(char *str)
> early_param("rodata", set_debug_rodata);
> #endif
>
> -#ifdef CONFIG_STRICT_KERNEL_RWX
> static void mark_readonly(void)
> {
> - if (rodata_enabled) {
> + if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX) && rodata_enabled) {
> /*
>* load_module() results in W+X mappings, which are cleaned
>* up with call_rcu(). Let's make sure that queued work is
> @@ -1409,20 +1408,14 @@ static void mark_readonly(void)
> rcu_barrier();
> mark_rodata_ro();
> rodata_test();
> - } else
> + } else if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)) {
> pr_info("Kernel memory protection disabled.\n");
> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_STRICT_KERNEL_RWX)) {
> + pr_warn("Kernel memory protection not selected by kernel
> config.\n");
> + } else {
> + pr_warn("This architecture does not have kernel memory
> protection.\n");
> + }
> }
> -#elif defined(CONFIG_ARCH_HAS_STRICT_KERNEL_RWX)
> -static inline void mark_readonly(void)
> -{
> - pr_warn("Kernel memory protection not selected by kernel config.\n");
> -}
> -#else
> -static inline void mark_readonly(void)
> -{
> - pr_warn("This architecture does not have kernel memory protection.\n");
> -}
> -#endif
>
> void __weak free_initmem(void)
> {
> --
> 2.41.0
Re: (subset) [PATCH v2 0/2] m68k/powerpc: Kill references to non-existent README.legal
On Mon, 18 Sep 2023 12:14:42 +0200, Geert Uytterhoeven wrote: > Note that the "COPYING" file at that time corresponded to the version > from upstream Linux v0.99.11 until v2.1.104, and thus predated the > addition of the "only valid GPL version is v2" clause in v2.4.0-test8. > > This patch series gets rid of the references to README.legal by > replacing the boilerplate with SPDX license identifiers. > > [...] Applied to powerpc/next. [2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX https://git.kernel.org/powerpc/c/6fcb13972bc2b41211e1dddb02f5e73199addc75 cheers
Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX
Geert Uytterhoeven writes: > Hi Michael, > > On Tue, Sep 19, 2023 at 4:13 AM Michael Ellerman wrote: >> Geert Uytterhoeven writes: >> > Upstream Linux never had a "README.legal" file, but it was present >> > in early source releases of Linux/m68k. It contained a simple copyright >> > notice and a link to a version of the "COPYING" file that predated the >> > addition of the "only valid GPL version is v2" clause. >> > >> > Get rid of the references to non-existent files by replacing the >> > boilerplate with SPDX license identifiers. >> > >> > Signed-off-by: Geert Uytterhoeven >> >> LGTM. >> >> Acked-by: Michael Ellerman (powerpc) > > Can you please take it through the PPC tree? Sure thing. cheers
Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX
Geert Uytterhoeven writes: > Upstream Linux never had a "README.legal" file, but it was present > in early source releases of Linux/m68k. It contained a simple copyright > notice and a link to a version of the "COPYING" file that predated the > addition of the "only valid GPL version is v2" clause. > > Get rid of the references to non-existent files by replacing the > boilerplate with SPDX license identifiers. > > Signed-off-by: Geert Uytterhoeven LGTM. Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set
Dan Williams writes:
> On Tue, Mar 22, 2022 at 7:30 AM kajoljain wrote:
>> On 3/22/22 03:09, Dan Williams wrote:
>> > On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
>> >>
>> >> The following build failure occures when CONFIG_PERF_EVENTS is not set
>> >> as generic pmu functions are not visible in that scenario.
>> >>
>> >> arch/powerpc/platforms/pseries/papr_scm.c:372:35: error: ‘struct
>> >> perf_event’ has no member named ‘attr’
>> >> p->nvdimm_events_map[event->attr.config],
>> >>^~
>> >> In file included from ./include/linux/list.h:5,
>> >> from ./include/linux/kobject.h:19,
>> >> from ./include/linux/of.h:17,
>> >> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>> >> arch/powerpc/platforms/pseries/papr_scm.c: In function
>> >> ‘papr_scm_pmu_event_init’:
>> >> arch/powerpc/platforms/pseries/papr_scm.c:389:49: error: ‘struct
>> >> perf_event’ has no member named ‘pmu’
>> >> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> >> ^~
>> >> ./include/linux/container_of.h:18:26: note: in definition of macro
>> >> ‘container_of’
>> >> void *__mptr = (void *)(ptr); \
>> >> ^~~
>> >> arch/powerpc/platforms/pseries/papr_scm.c:389:30: note: in expansion of
>> >> macro ‘to_nvdimm_pmu’
>> >> struct nvdimm_pmu *nd_pmu = to_nvdimm_pmu(event->pmu);
>> >> ^
>> >> In file included from ./include/linux/bits.h:22,
>> >> from ./include/linux/bitops.h:6,
>> >> from ./include/linux/of.h:15,
>> >> from arch/powerpc/platforms/pseries/papr_scm.c:5:
>> >>
>> >> Fix the build issue by adding check for CONFIG_PERF_EVENTS config option
>> >> and disabling the papr_scm perf interface support incase this config
>> >> is not set
>> >>
>> >> Fixes: 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
>> >> (Commit id
>> >> based on linux-next tree)
>> >> Signed-off-by: Kajol Jain
>> >> ---
>> >> arch/powerpc/platforms/pseries/papr_scm.c | 15 +++
>> >
>> > This is a bit messier than I would have liked mainly because it dumps
>> > a bunch of ifdefery into a C file contrary to coding style, "Wherever
>> > possible, don't use preprocessor conditionals (#if, #ifdef) in .c
>> > files". I would expect this all to move to an organization like:
>>
>> Hi Dan,
>> Thanks for reviewing the patches. Inorder to avoid the multiple
>> ifdefs checks, we can also add stub function for papr_scm_pmu_register.
>> With that change we will just have one ifdef check for
>> CONFIG_PERF_EVENTS config in both papr_scm.c and nd.h file. Hence we can
>> avoid adding new files specific for papr_scm perf interface.
>>
>> Below is the code snippet for that change, let me know if looks fine to
>> you. I tested it
>> with set/unset PAPR_SCM config value and set/unset PERF_EVENTS config
>> value combinations.
>>
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
>> b/arch/powerpc/platforms/pseries/papr_scm.c
>> index 4dd513d7c029..38fabb44d3c3 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -69,8 +69,6 @@
>> #define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
>> #define PAPR_SCM_PERF_STATS_VERSION 0x1
>>
>> -#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
>> -
>> /* Struct holding a single performance metric */
>> struct papr_scm_perf_stat {
>> u8 stat_id[8];
>> @@ -346,6 +344,9 @@ static ssize_t drc_pmem_query_stats(struct
>> papr_scm_priv *p,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_PERF_EVENTS
>> +#define to_nvdimm_pmu(_pmu)container_of(_pmu, struct nvdimm_pmu, pmu)
>> +
>> static int papr_scm_pmu_get_value(struct perf_event *event, struct
>> device *dev, u64 *count)
>> {
>> struct papr_scm_perf_stat *stat;
>> @@ -558,6 +559,10 @@ static void papr_scm_pmu_register(struct
>> papr_scm_priv *p)
>> dev_info(>pdev->dev, "nvdimm pmu didn't register rc=%d\n", rc);
>> }
>>
>> +#else
>> +static inline void papr_scm_pmu_register(struct papr_scm_priv *p) { }
>
> Since this isn't in a header file, it does not need to be marked
> "inline" the compiler will figure it out.
>
>> +#endif
>
> It might be time to create:
>
> arch/powerpc/platforms/pseries/papr_scm.h
>
> ...there is quite a bit of header material accrued in papr_scm.c and
> once the ifdefs start landing in it then it becomes a nominal coding
> style issue. That said, this is certainly more palatable than the
> previous version. So if you don't want to create papr_scm.h yet for
> this, at least make a note in the changelog that the first portion of
> arch/powerpc/platforms/pseries/papr_scm.c is effectively papr_scm.h
> content and may move there in the future, or something like that.
IMHO the only thing that belongs in a header is content that's needed by
Re: [RFC PATCH v2] powerpc/papr_scm: Move duplicate definitions to common header files
Shivaprasad G Bhat writes: > papr_scm and ndtest share common PDSM payload structs like > nd_papr_pdsm_health. Presently these structs are duplicated across papr_pdsm.h > and ndtest.h header files. Since 'ndtest' is essentially arch independent and > can > run on platforms other than PPC64, a way needs to be deviced to avoid > redundancy > and duplication of PDSM structs in future. > > So the patch proposes moving the PDSM header from arch/powerpc/include/uapi/ > to > the generic include/uapi/linux directory. Also, there are some #defines common > between papr_scm and ndtest which are not exported to the user space. So, move > them to a header file which can be shared across ndtest and papr_scm via newly > introduced include/linux/papr_scm.h. > > Signed-off-by: Shivaprasad G Bhat > Signed-off-by: Vaibhav Jain > Suggested-by: "Aneesh Kumar K.V" > --- > Changelog: > > Since v1: > Link: > https://patchwork.kernel.org/project/linux-nvdimm/patch/162505488483.72147.12741153746322191381.stgit@56e104a48989/ > * Removed dependency on this patch for the other patches > > MAINTAINERS |2 > arch/powerpc/include/uapi/asm/papr_pdsm.h | 165 > - > arch/powerpc/platforms/pseries/papr_scm.c | 43 > include/linux/papr_scm.h | 48 > include/uapi/linux/papr_pdsm.h| 165 > + This doesn't make sense to me. Anything with papr (or PAPR) in the name is fundamentally powerpc specific, it doesn't belong in a generic header, or in a generic location. What's the actual problem you're trying to solve? If it's just including papr_scm bits into ndtest.c then that should be as simple as: #ifdef __powerpc__ #include #endif Shouldn't it? cheers
Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
Christophe Leroy writes: > Le 19/04/2021 à 23:39, Randy Dunlap a écrit : >> On 4/19/21 6:16 AM, Michael Ellerman wrote: >>> Randy Dunlap writes: >> >>>> Sure. I'll post them later today. >>>> They keep FPU and ALTIVEC as independent (build) features. >>> >>> Those patches look OK. >>> >>> But I don't think it makes sense to support that configuration, FPU=n >>> ALTVEC=y. No one is ever going to make a CPU like that. We have enough >>> testing surface due to configuration options, without adding artificial >>> combinations that no one is ever going to use. >>> >>> IMHO :) >>> >>> So I'd rather we just make ALTIVEC depend on FPU. >> >> That's rather simple. See below. >> I'm doing a bunch of randconfig builds with it now. >> >> --- >> From: Randy Dunlap >> Subject: [PATCH] powerpc: make ALTIVEC depend PPC_FPU >> >> On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled, >> there are build errors: >> >> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of >> function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration] >> enable_kernel_fp(); >> ../arch/powerpc/lib/sstep.c: In function 'do_vec_load': >> ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function >> 'put_vr' [-Werror=implicit-function-declaration] >>637 | put_vr(rn, ); >>| ^~ >> ../arch/powerpc/lib/sstep.c: In function 'do_vec_store': >> ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function >> 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration] >>660 | get_vr(rn, ); >>| ^~ >> >> In theory ALTIVEC is independent of PPC_FPU but in practice nobody >> is going to build such a machine, so make ALTIVEC require PPC_FPU >> by depending on PPC_FPU. >> >> Signed-off-by: Randy Dunlap >> Reported-by: kernel test robot >> Cc: Michael Ellerman >> Cc: linuxppc-...@lists.ozlabs.org >> Cc: Christophe Leroy >> Cc: Segher Boessenkool >> Cc: l...@intel.com >> --- >> arch/powerpc/platforms/86xx/Kconfig|1 + >> arch/powerpc/platforms/Kconfig.cputype |2 ++ >> 2 files changed, 3 insertions(+) >> >> --- linux-next-20210416.orig/arch/powerpc/platforms/86xx/Kconfig >> +++ linux-next-20210416/arch/powerpc/platforms/86xx/Kconfig >> @@ -4,6 +4,7 @@ menuconfig PPC_86xx >> bool "86xx-based boards" >> depends on PPC_BOOK3S_32 >> select FSL_SOC >> +select PPC_FPU >> select ALTIVEC >> help >>The Freescale E600 SoCs have 74xx cores. >> --- linux-next-20210416.orig/arch/powerpc/platforms/Kconfig.cputype >> +++ linux-next-20210416/arch/powerpc/platforms/Kconfig.cputype >> @@ -186,6 +186,7 @@ config E300C3_CPU >> config G4_CPU >> bool "G4 (74xx)" >> depends on PPC_BOOK3S_32 >> +select PPC_FPU >> select ALTIVEC >> >> endchoice >> @@ -309,6 +310,7 @@ config PHYS_64BIT >> >> config ALTIVEC >> bool "AltiVec Support" >> +depends on PPC_FPU > > Shouldn't we do it the other way round ? In extenso make ALTIVEC select > PPC_FPU and avoid the two > selects that are above ? Yes, ALTIVEC should select PPC_FPU. The latter is (generally) not user selectable, so there's no issue with selecting it, whereas the reverse is not true. For 64-bit Book3S I think we could just always enable ALTIVEC these days. It's only Power5 that doesn't have it, and essentially no one is running mainline on those AFAIK. But that can be done separately. cheers
Re: [PATCH 0/2] Change struct page layout for page_pool
"Matthew Wilcox (Oracle)" writes: > The first patch here fixes two bugs on ppc32, and mips32. It fixes one > bug on arc and arm32 (in certain configurations). It probably makes > sense to get it in ASAP through the networking tree. I'd like to see > testing on those four architectures if possible? Sorry I don't have easy access to any hardware that fits the bill. At some point I'll be able to go to the office and setup a machine that (I think) can test these paths, but I don't have an ETA on that. You and others seem to have done lots of analysis on this though, so I think you should merge the fixes without waiting on ppc32 testing. cheers > > The second patch enables new functionality. It is much less urgent. > I'd really like to see Mel & Michal's thoughts on it. > > I have only compile-tested these patches. > > Matthew Wilcox (Oracle) (2): > mm: Fix struct page layout on 32-bit systems > mm: Indicate pfmemalloc pages in compound_head > > include/linux/mm.h | 12 +++- > include/linux/mm_types.h | 9 - > include/net/page_pool.h | 12 +++- > net/core/page_pool.c | 12 +++- > 4 files changed, 29 insertions(+), 16 deletions(-) > > -- > 2.30.2
Re: [PATCH] powerpc/pseries: Add shutdown() to vio_driver and vio_bus
Tyrel Datwyler writes: > On 4/17/21 5:30 AM, Michael Ellerman wrote: >> Tyrel Datwyler writes: >>> On 4/1/21 5:13 PM, Tyrel Datwyler wrote: >>>> Currently, neither the vio_bus or vio_driver structures provide support >>>> for a shutdown() routine. >>>> >>>> Add support for shutdown() by allowing drivers to provide a >>>> implementation via function pointer in their vio_driver struct and >>>> provide a proper implementation in the driver template for the vio_bus >>>> that calls a vio drivers shutdown() if defined. >>>> >>>> In the case that no shutdown() is defined by a vio driver and a kexec is >>>> in progress we implement a big hammer that calls remove() to ensure no >>>> further DMA for the devices is possible. >>>> >>>> Signed-off-by: Tyrel Datwyler >>>> --- >>> >>> Ping... any comments, problems with this approach? >> >> The kexec part seems like a bit of a hack. >> >> It also doesn't help for kdump, when none of the shutdown code is run. > > If I understand correctly for kdump we have a reserved memory space where the > kdump kernel is loaded, but for kexec the memory region isn't reserved ahead > of > time meaning we can try and load the kernel over potential memory used for DMA > by the current kernel. That's correct. >> How many drivers do we have? Can we just implement a proper shutdown for >> them? > > Well that is the end goal. I just don't currently have the bandwidth to do > each > driver myself with a proper shutdown sequence, and thought this was a > launching > off point to at least introduce the shutdown callback to the VIO bus. Fair enough. > Off the top of my head we have 3 storage drivers, 2 network drivers, vtpm, > vmc, > pseries_rng, nx, nx842, hvcs, hvc_vio. > > I can drop the kexec_in_progress hammer and just have each driver call > remove() > themselves in their shutdown function. Leave it to each maintainer to decide > if > remove() is enough or if there is a more lightweight quiesce sequence they > choose to implement. That's OK, you've convinced me. I'll take it as-is. Eventually it would be good for drivers to implement shutdown in the optimal way for their device, but that can be done incrementally. cheers
Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
Randy Dunlap writes: > On 4/18/21 10:46 AM, Segher Boessenkool wrote: >> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote: >>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit : Should the code + Kconfigs/Makefiles handle that kind of kernel config or should ALTIVEC always mean PPC_FPU as well? >>> >>> As far as I understand, Altivec is completely independant of FPU in Theory. >> >> And, as far as the hardware is concerned, in practice as well. >> >>> So it should be possible to use Altivec without using FPU. >> >> Yup. >> >>> However, until recently, it was not possible to de-activate FPU support on >>> book3s/32. I made it possible in order to reduce unneccessary processing on >>> processors like the 832x that has no FPU. >> >> The processor has to implement FP to be compliant to any version of >> PowerPC, as far as I know? So that is all done by emulation, including >> all the registers? Wow painful. >> >>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without >>> FPU, and it doesn't have ALTIVEC either. >> >> 602 doesn't have double-precision hardware, also no 64-bit FP registers. >> But that CPU was never any widely used :-) >> >>> So we can in the future ensure that Altivec can be used without FPU >>> support, but for the time being I think it is OK to force selection of FPU >>> when selecting ALTIVEC in order to avoid build failures. >> >> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that >> have VMX (aka AltiVec) but that do not have FP. I don't see how making >> that artificial dependency buys anything, but maybe it does? >> I have patches to fix the build errors with the config as reported but I don't know if that's the right thing to do... >> >> Neither do we, we cannot see those patches :-) > > Sure. I'll post them later today. > They keep FPU and ALTIVEC as independent (build) features. Those patches look OK. But I don't think it makes sense to support that configuration, FPU=n ALTVEC=y. No one is ever going to make a CPU like that. We have enough testing surface due to configuration options, without adding artificial combinations that no one is ever going to use. IMHO :) So I'd rather we just make ALTIVEC depend on FPU. cheers
Re: [PATCH v2] perf vendor events: Initial json/events list for power10 platform
Kajol Jain writes:
> Patch adds initial json/events for POWER10.
Acked-by: Michael Ellerman
cheers
> Signed-off-by: Kajol Jain
> Tested-by: Paul A. Clarke
> Reviewed-by: Paul A. Clarke
> ---
> .../perf/pmu-events/arch/powerpc/mapfile.csv | 1 +
> .../arch/powerpc/power10/cache.json | 47 +++
> .../arch/powerpc/power10/floating_point.json | 7 +
> .../arch/powerpc/power10/frontend.json| 217 +
> .../arch/powerpc/power10/locks.json | 12 +
> .../arch/powerpc/power10/marked.json | 147 +
> .../arch/powerpc/power10/memory.json | 192 +++
> .../arch/powerpc/power10/others.json | 297 ++
> .../arch/powerpc/power10/pipeline.json| 297 ++
> .../pmu-events/arch/powerpc/power10/pmc.json | 22 ++
> .../arch/powerpc/power10/translation.json | 57
> 11 files changed, 1296 insertions(+)
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/cache.json
> create mode 100644
> tools/perf/pmu-events/arch/powerpc/power10/floating_point.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/frontend.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/locks.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/marked.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/memory.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/others.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/pipeline.json
> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/pmc.json
> create mode 100644
> tools/perf/pmu-events/arch/powerpc/power10/translation.json
>
> ---
> Changelog:
> v1 -> v2
> - Removed inconsistencies in "BriefDescription" field and make sure
> it will end with period without any space at the end.
> Suggested by : Paul A. Clarke
> - Added Tested-by and Reviewed-by tag.
> ---
> diff --git a/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> b/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> index 229150e7ab7d..4abdfc3f9692 100644
> --- a/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> +++ b/tools/perf/pmu-events/arch/powerpc/mapfile.csv
> @@ -15,3 +15,4 @@
> # Power8 entries
> 004[bcd][[:xdigit:]]{4},1,power8,core
> 004e[[:xdigit:]]{4},1,power9,core
> +0080[[:xdigit:]]{4},1,power10,core
> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/cache.json
> b/tools/perf/pmu-events/arch/powerpc/power10/cache.json
> new file mode 100644
> index ..95e33531fbc6
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/powerpc/power10/cache.json
> @@ -0,0 +1,47 @@
> +[
> + {
> +"EventCode": "1003C",
> +"EventName": "PM_EXEC_STALL_DMISS_L2L3",
> +"BriefDescription": "Cycles in which the oldest instruction in the
> pipeline was waiting for a load miss to resolve from either the local L2 or
> local L3."
> + },
> + {
> +"EventCode": "34056",
> +"EventName": "PM_EXEC_STALL_LOAD_FINISH",
> +"BriefDescription": "Cycles in which the oldest instruction in the
> pipeline was finishing a load after its data was reloaded from a data source
> beyond the local L1; cycles in which the LSU was processing an L1-hit; cycles
> in which the NTF instruction merged with another load in the LMQ."
> + },
> + {
> +"EventCode": "3006C",
> +"EventName": "PM_RUN_CYC_SMT2_MODE",
> +"BriefDescription": "Cycles when this thread's run latch is set and the
> core is in SMT2 mode."
> + },
> + {
> +"EventCode": "300F4",
> +"EventName": "PM_RUN_INST_CMPL_CONC",
> +"BriefDescription": "PowerPC instructions completed by this thread when
> all threads in the core had the run-latch set."
> + },
> + {
> +"EventCode": "4C016",
> +"EventName": "PM_EXEC_STALL_DMISS_L2L3_CONFLICT",
> +"BriefDescription": "Cycles in which the oldest instruction in the
> pipeline was waiting for a load miss to resolve from the local L2 or local
> L3, with a dispatch conflict."
> + },
> + {
> +"EventCode": "4D014",
> +"EventName": "PM_EXEC_STALL_LOAD",
> +"BriefDescription": "Cycles in which the oldest instruction in the
> pipeline was a load instruction executing in the Load Store Unit."
> + },
> + {
> +"EventCode": "4D016",
> +
Re: linux-next: build failure after merge of the powerpc tree
Xiongwei Song writes: > Thank you so much Stephen. Sorry for my negligence. My fault. I forgot to run allyesconfig. > Should I fix this myself on powerpc tree? I'll fix it up. cheers
Re: [PATCH v3] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
On Thu, 17 Sep 2020 06:54:37 -0700, Tony Ambardar wrote: > A few archs like powerpc have different errno.h values for macros > EDEADLOCK and EDEADLK. In code including both libc and linux versions of > errno.h, this can result in multiple definitions of EDEADLOCK in the > include chain. Definitions to the same value (e.g. seen with mips) do > not raise warnings, but on powerpc there are redefinitions changing the > value, which raise warnings and errors (if using "-Werror"). > > [...] Applied to powerpc/next. [1/1] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h https://git.kernel.org/powerpc/c/7de21e679e6a789f3729e8402bc440b623a28eae cheers
Re: [PATCH] windfarm: make symbol 'wf_thread' static
On Wed, 7 Apr 2021 20:57:38 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/windfarm_core.c:59:20: warning: > symbol 'wf_thread' was not declared. Should it be static? > > This symbol is not used outside of windfarm_core.c, so this > commit marks it static. Applied to powerpc/next. [1/1] windfarm: make symbol 'wf_thread' static https://git.kernel.org/powerpc/c/4204ecd598cb0a044e6fcfd48e569080955347f4 cheers
Re: [PATCH] powerpc/smp: Make some symbols static
On Wed, 7 Apr 2021 20:59:03 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/smp.c:86:1: warning: > symbol '__pcpu_scope_cpu_coregroup_map' was not declared. Should it be > static? > arch/powerpc/kernel/smp.c:125:1: warning: > symbol '__pcpu_scope_thread_group_l1_cache_map' was not declared. Should it > be static? > arch/powerpc/kernel/smp.c:132:1: warning: > symbol '__pcpu_scope_thread_group_l2_cache_map' was not declared. Should it > be static? > > [...] Applied to powerpc/next. [1/1] powerpc/smp: Make some symbols static https://git.kernel.org/powerpc/c/078277acbd7c3fdb25c01a3cd5b4a1a875a1ab2f cheers
Re: [PATCH] macintosh/windfarm: Make symbol 'pm121_sys_state' static
On Wed, 7 Apr 2021 20:57:12 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/windfarm_pm121.c:436:24: warning: > symbol 'pm121_sys_state' was not declared. Should it be static? > > This symbol is not used outside of windfarm_pm121.c, so this > commit marks it static. Applied to powerpc/next. [1/1] macintosh/windfarm: Make symbol 'pm121_sys_state' static https://git.kernel.org/powerpc/c/13ddd0e3acf988a98b46800178ae691640b0cd00 cheers
Re: [PATCH] macintosh/via-pmu: Make some symbols static
On Wed, 7 Apr 2021 20:58:03 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/via-pmu.c:183:5: warning: > symbol 'pmu_cur_battery' was not declared. Should it be static? > drivers/macintosh/via-pmu.c:190:5: warning: > symbol '__fake_sleep' was not declared. Should it be static? > > [...] Applied to powerpc/next. [1/1] macintosh/via-pmu: Make some symbols static https://git.kernel.org/powerpc/c/95d143923379ffb0e706b064305681d44c05ec4b cheers
Re: [PATCH] powerpc/pseries: extract host bridge from pci_bus prior to bus removal
On Thu, 11 Feb 2021 12:24:35 -0600, Tyrel Datwyler wrote: > The pci_bus->bridge reference may no longer be valid after > pci_bus_remove() resulting in passing a bad value to device_unregister() > for the associated bridge device. > > Store the host_bridge reference in a separate variable prior to > pci_bus_remove(). Applied to powerpc/next. [1/1] powerpc/pseries: extract host bridge from pci_bus prior to bus removal https://git.kernel.org/powerpc/c/38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 cheers
Re: [PATCH v5] powerpc/traps: Enhance readability for trap types
On Wed, 14 Apr 2021 19:00:33 +0800, Xiongwei Song wrote: > Define macros to list ppc interrupt types in interttupt.h, replace the > reference of the trap hex values with these macros. > > Referred the hex numbers in arch/powerpc/kernel/exceptions-64e.S, > arch/powerpc/kernel/exceptions-64s.S, arch/powerpc/kernel/head_*.S, > arch/powerpc/kernel/head_booke.h and arch/powerpc/include/asm/kvm_asm.h. > > [...] Applied to powerpc/next. [1/1] powerpc/traps: Enhance readability for trap types https://git.kernel.org/powerpc/c/7153d4bf0b373428d0393c001019da4d0483fddb cheers
Re: [PATCH -next] powerpc/fadump: make symbol 'rtas_fadump_set_regval' static
On Thu, 8 Apr 2021 14:20:12 +0800, Pu Lehui wrote: > Fix sparse warnings: > > arch/powerpc/platforms/pseries/rtas-fadump.c:250:6: warning: > symbol 'rtas_fadump_set_regval' was not declared. Should it be static? Applied to powerpc/next. [1/1] powerpc/fadump: make symbol 'rtas_fadump_set_regval' static https://git.kernel.org/powerpc/c/59fd366b9bef2d048af763e27cd1622ee5a1dfd4 cheers
Re: [PATCH -next] powerpc/xmon: Make symbol 'spu_inst_dump' static
On Fri, 9 Apr 2021 15:01:51 +0800, Pu Lehui wrote: > Fix sparse warning: > > arch/powerpc/xmon/xmon.c:4216:1: warning: > symbol 'spu_inst_dump' was not declared. Should it be static? > > This symbol is not used outside of xmon.c, so make it static. Applied to powerpc/next. [1/1] powerpc/xmon: Make symbol 'spu_inst_dump' static https://git.kernel.org/powerpc/c/f234ad405a35262ed2d8dd2d29fc633908dce955 cheers
Re: [PATCH -next] powerpc/mce: Make symbol 'mce_ue_event_work' static
On Thu, 8 Apr 2021 11:58:02 +0800, Li Huafei wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/mce.c:43:1: warning: > symbol 'mce_ue_event_work' was not declared. Should it be static? > > This symbol is not used outside of mce.c, so this commit marks it > static. Applied to powerpc/next. [1/1] powerpc/mce: Make symbol 'mce_ue_event_work' static https://git.kernel.org/powerpc/c/f6f1f48e8b3b242dfa684d6e1b930d239d87533a cheers
Re: [PATCH v3 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
On Thu, 8 Apr 2021 17:19:16 -0300, Leonardo Bras wrote: > According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes" > will let the OS know all possible pagesizes that can be used for creating a > new DDW. > > Currently Linux will only try using 3 of the 8 available options: > 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M, > 128M, 256M and 16G. > > [...] Applied to powerpc/next. [1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR https://git.kernel.org/powerpc/c/472724111f0f72042deb6a9dcee9578e5398a1a1 cheers
Re: [PATCH -next] powerpc/perf/hv-24x7: Make some symbols static
On Fri, 9 Apr 2021 17:01:24 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/perf/hv-24x7.c:229:1: warning: > symbol '__pcpu_scope_hv_24x7_txn_flags' was not declared. Should it be > static? > arch/powerpc/perf/hv-24x7.c:230:1: warning: > symbol '__pcpu_scope_hv_24x7_txn_err' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:236:1: warning: > symbol '__pcpu_scope_hv_24x7_hw' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:244:1: warning: > symbol '__pcpu_scope_hv_24x7_reqb' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:245:1: warning: > symbol '__pcpu_scope_hv_24x7_resb' was not declared. Should it be static? > > [...] Applied to powerpc/next. [1/1] powerpc/perf/hv-24x7: Make some symbols static https://git.kernel.org/powerpc/c/cc331eee03eadd750af1fb957d020b3f24e5e056 cheers
Re: [PATCH -next] powerpc/security: Make symbol 'stf_barrier' static
On Thu, 8 Apr 2021 11:39:51 +0800, Li Huafei wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/security.c:253:6: warning: > symbol 'stf_barrier' was not declared. Should it be static? > > This symbol is not used outside of security.c, so this commit marks it > static. Applied to powerpc/next. [1/1] powerpc/security: Make symbol 'stf_barrier' static https://git.kernel.org/powerpc/c/7f262b4dcf7edf75097c3946e676d6c6d77fc599 cheers
Re: [PATCH 1/2] powerpc: syscalls: switch to generic syscalltbl.sh
On Tue, 2 Mar 2021 00:30:18 +0900, Masahiro Yamada wrote: > Many architectures duplicate similar shell scripts. > > This commit converts powerpc to use scripts/syscalltbl.sh. This also > unifies syscall_table_32.h and syscall_table_c32.h. Applied to powerpc/next. [1/2] powerpc: syscalls: switch to generic syscalltbl.sh https://git.kernel.org/powerpc/c/14b3c9d24a7a5c274a9df27d245516f466d3bc5f [2/2] powerpc: syscalls: switch to generic syscallhdr.sh https://git.kernel.org/powerpc/c/672bff581e19d5d7bef993f910ed385c4054cbbc cheers
Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
On Fri, 26 Mar 2021 19:17:20 +, Dmitry Safonov wrote:
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
> Laurent made a patch to keep CRIU working (by reading aux vector).
> But I think it still makes sence to separate two mappings into different
> VMAs. It will also make ppc64 less "special" for userspace and as
> a side-bonus will make VVAR page un-writable by debugger (which previously
> would COW page and can be unexpected).
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/vdso: Separate vvar vma from vdso
https://git.kernel.org/powerpc/c/1c4bce6753857dc409a0197342d18764e7f4b741
cheers
Re: [PATCH -next] powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static
On Fri, 9 Apr 2021 17:01:14 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/pseries/pmem.c:142:27: warning: > symbol 'drc_pmem_match' was not declared. Should it be static? > > This symbol is not used outside of pmem.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static https://git.kernel.org/powerpc/c/2235dea17d56238642121a8085b71d68598534bb cheers
Re: [PATCH -next] powerpc/pseries: Make symbol '__pcpu_scope_hcall_stats' static
On Fri, 9 Apr 2021 17:01:09 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/pseries/hvCall_inst.c:29:1: warning: > symbol '__pcpu_scope_hcall_stats' was not declared. Should it be static? > > This symbol is not used outside of hvCall_inst.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/pseries: Make symbol '__pcpu_scope_hcall_stats' static https://git.kernel.org/powerpc/c/193e4cd8ed9dd01092d01df7706a6b344c946af4 cheers
Re: [PATCH -next] powerpc/powernv: make symbol 'mpipl_kobj' static
On Fri, 9 Apr 2021 14:38:55 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/powernv/opal-core.c:74:16: warning: > symbol 'mpipl_kobj' was not declared. > > This symbol is not used outside of opal-core.c, so marks it static. Applied to powerpc/next. [1/1] powerpc/powernv: make symbol 'mpipl_kobj' static https://git.kernel.org/powerpc/c/ff0b4155ae9903539d1299a9a4c8717fb7eb6009 cheers
Re: [PATCH -next] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static
On Fri, 9 Apr 2021 17:01:19 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/perf/isa207-common.c:24:18: warning: > symbol 'isa207_pmu_format_attr' was not declared. Should it be static? > > This symbol is not used outside of isa207-common.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static https://git.kernel.org/powerpc/c/107dadb046178173dea18e0a78ff8ea3cc27c213 cheers
Re: [PATCH RESEND v1 0/4] powerpc/vdso: Add support for time namespaces
On Wed, 31 Mar 2021 16:48:43 + (UTC), Christophe Leroy wrote: > [Sorry, resending with complete destination list, I used the wrong script on > the first delivery] > > This series adds support for time namespaces on powerpc. > > All timens selftests are successfull. > > Christophe Leroy (3): > lib/vdso: Mark do_hres_timens() and do_coarse_timens() > __always_inline() > lib/vdso: Add vdso_data pointer as input to > __arch_get_timens_vdso_data() > powerpc/vdso: Add support for time namespaces > > [...] Applied to powerpc/next. [1/4] lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline() https://git.kernel.org/powerpc/c/58efe9f696cf908f40d6672aeca81cb2ad2bc762 [2/4] lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data() https://git.kernel.org/powerpc/c/808094fcbf4196be0feb17afbbdc182ec95c8cec [3/4] powerpc/vdso: Separate vvar vma from vdso https://git.kernel.org/powerpc/c/1c4bce6753857dc409a0197342d18764e7f4b741 [4/4] powerpc/vdso: Add support for time namespaces https://git.kernel.org/powerpc/c/74205b3fc2effde821b219d955c70e727dc43cc6 cheers
Re: [PATCH v2 1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c
On Thu, 8 Apr 2021 15:30:24 + (UTC), Christophe Leroy wrote: > Cache flushing functions are in the middle of completely > unrelated stuff in mm/mem.c > > Create a dedicated mm/cacheflush.c for those functions. > > Also cleanup the list of included headers. Applied to powerpc/next. [1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c https://git.kernel.org/powerpc/c/b26e8f27253a47bff90972b987112fd8396e9b8d [2/9] powerpc/mem: Declare __flush_dcache_icache() static https://git.kernel.org/powerpc/c/bf26e0bbd2f82b52605cd7c880245eefe67e09f3 [3/9] powerpc/mem: Remove address argument to flush_coherent_icache() https://git.kernel.org/powerpc/c/131637a17dc97fde3d007ab224e30c7ff4e62f6e [4/9] powerpc/mem: Call flush_coherent_icache() at higher level https://git.kernel.org/powerpc/c/e618c7aea1f2a2d615a99948f1f5cb4c11b6bf57 [5/9] powerpc/mem: Optimise flush_dcache_icache_hugepage() https://git.kernel.org/powerpc/c/cd97d9e8b5aa45a7f867a10e99f1d6ce0a5deb8b [6/9] powerpc/mem: flush_dcache_icache_phys() is for HIGHMEM pages only https://git.kernel.org/powerpc/c/52d490437ffb1bab0a63ab7b1a64514d8c17dd4d [7/9] powerpc/mem: Help GCC realise __flush_dcache_icache() flushes single pages https://git.kernel.org/powerpc/c/67b8e6af191a6ed717be548307eb15048f8181d8 [8/9] powerpc/mem: Inline flush_dcache_page() https://git.kernel.org/powerpc/c/6c96020882b17fb6f4fbf7f8cef8c606460fc14d [9/9] powerpc/mem: Use kmap_local_page() in flushing functions https://git.kernel.org/powerpc/c/7e9ab144c128df7660a2f33c9c6d1422fe798060 cheers
Re: [PATCH] powerpc/signal32: Fix build failure with CONFIG_SPE
On Sun, 11 Apr 2021 16:39:53 + (UTC), Christophe Leroy wrote: > Add missing fault exit label in unsafe_copy_from_user() in order to > avoid following build failure with CONFIG_SPE > > CC arch/powerpc/kernel/signal_32.o > arch/powerpc/kernel/signal_32.c: In function 'restore_user_regs': > arch/powerpc/kernel/signal_32.c:565:36: error: macro "unsafe_copy_from_user" > requires 4 arguments, but only 3 given > 565 | ELF_NEVRREG * sizeof(u32)); > |^ > In file included from ./include/linux/uaccess.h:11, > from ./include/linux/sched/task.h:11, > from ./include/linux/sched/signal.h:9, > from ./include/linux/rcuwait.h:6, > from ./include/linux/percpu-rwsem.h:7, > from ./include/linux/fs.h:33, > from ./include/linux/huge_mm.h:8, > from ./include/linux/mm.h:707, > from arch/powerpc/kernel/signal_32.c:17: > ./arch/powerpc/include/asm/uaccess.h:428: note: macro "unsafe_copy_from_user" > defined here > 428 | #define unsafe_copy_from_user(d, s, l, e) \ > | > arch/powerpc/kernel/signal_32.c:564:3: error: 'unsafe_copy_from_user' > undeclared (first use in this function); did you mean 'raw_copy_from_user'? > 564 | unsafe_copy_from_user(current->thread.evr, >mc_vregs, > | ^ > | raw_copy_from_user > arch/powerpc/kernel/signal_32.c:564:3: note: each undeclared identifier is > reported only once for each function it appears in > make[3]: *** [arch/powerpc/kernel/signal_32.o] Error 1 Applied to powerpc/next. [1/1] powerpc/signal32: Fix build failure with CONFIG_SPE https://git.kernel.org/powerpc/c/af072b1a9d4d9edc24da84a071b0671e147026cb cheers
Re: [PATCH 1/3] powerpc/modules: Load modules closer to kernel text
On Thu, 1 Apr 2021 13:30:41 + (UTC), Christophe Leroy wrote: > On book3s/32, when STRICT_KERNEL_RWX is selected, modules are > allocated on the segment just before kernel text, ie on the > 0xb000-0xbfff when PAGE_OFFSET is 0xc000. > > On the 8xx, TASK_SIZE is 0x8000. The space between TASK_SIZE and > PAGE_OFFSET is not used and could be used for modules. > > [...] Applied to powerpc/next. [1/3] powerpc/modules: Load modules closer to kernel text https://git.kernel.org/powerpc/c/2ec13df167040cd153c25c4d96d0ffc573ac4c40 [2/3] powerpc/8xx: Define a MODULE area below kernel text https://git.kernel.org/powerpc/c/9132a2e82adc6e5a1c7c7385df3bfb25576bdd80 [3/3] powerpc/32s: Define a MODULE area below kernel text all the time https://git.kernel.org/powerpc/c/80edc68e0479bafdc4869ec3351e42316b824596 cheers
Re: [PATCH] powerpc/pseries: Add shutdown() to vio_driver and vio_bus
Tyrel Datwyler writes: > On 4/1/21 5:13 PM, Tyrel Datwyler wrote: >> Currently, neither the vio_bus or vio_driver structures provide support >> for a shutdown() routine. >> >> Add support for shutdown() by allowing drivers to provide a >> implementation via function pointer in their vio_driver struct and >> provide a proper implementation in the driver template for the vio_bus >> that calls a vio drivers shutdown() if defined. >> >> In the case that no shutdown() is defined by a vio driver and a kexec is >> in progress we implement a big hammer that calls remove() to ensure no >> further DMA for the devices is possible. >> >> Signed-off-by: Tyrel Datwyler >> --- > > Ping... any comments, problems with this approach? The kexec part seems like a bit of a hack. It also doesn't help for kdump, when none of the shutdown code is run. How many drivers do we have? Can we just implement a proper shutdown for them? cheers
Re: linux-next: build warning after merge of the powerpc tree
Stephen Rothwell writes:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
>
> In file included from include/linux/device.h:15,
> from arch/powerpc/include/asm/io.h:27,
> from include/linux/io.h:13,
> from include/linux/irq.h:20,
> from arch/powerpc/include/asm/hardirq.h:6,
> from include/linux/hardirq.h:11,
> from include/linux/highmem.h:10,
> from include/linux/bio.h:8,
> from include/linux/libnvdimm.h:14,
> from arch/powerpc/platforms/pseries/papr_scm.c:12:
> arch/powerpc/platforms/pseries/papr_scm.c: In function 'papr_scm_pmem_flush':
> arch/powerpc/platforms/pseries/papr_scm.c:144:26: warning: format '%lld'
> expects argument of type 'long long int', but argument 3 has type 'long int'
> [-Wformat=]
> 144 | dev_err(>pdev->dev, "flush error: %lld", rc);
> | ^~~
> include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
>19 | #define dev_fmt(fmt) fmt
> | ^~~
> arch/powerpc/platforms/pseries/papr_scm.c:144:3: note: in expansion of macro
> 'dev_err'
> 144 | dev_err(>pdev->dev, "flush error: %lld", rc);
> | ^~~
> arch/powerpc/platforms/pseries/papr_scm.c:144:43: note: format string is
> defined here
> 144 | dev_err(>pdev->dev, "flush error: %lld", rc);
> |~~~^
> | |
> | long long int
> |%ld
>
> Introduced by commit
>
> 75b7c05ebf90 ("powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall")
My bad.
cheers
Re: [PATCH v3] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
Tony Ambardar writes: > Hello Michael, > > The latest version of this patch addressed all feedback I'm aware of > when submitted last September, and I've seen no further comments from > reviewers since then. > > Could you please let me know where this stands and if anything further > is needed? Sorry, it's still sitting in my inbox :/ I was going to reply to suggest we split the tools change out. The headers under tools are usually updated by another maintainer, I think it might even be scripted. Anyway I've applied your patch and done that (dropped the change to tools/.../errno.h), which should also mean the stable backport is more likely to work automatically. It will hit mainline in v5.13-rc1 and then be backported to the stable trees. I don't think you actually need the tools version of the header updated to fix your bug? In which case we can probably just wait for it to be updated automatically when the tools headers are sync'ed with the kernel versions. cheers > On Thu, 17 Sept 2020 at 06:54, Tony Ambardar wrote: >> >> A few archs like powerpc have different errno.h values for macros >> EDEADLOCK and EDEADLK. In code including both libc and linux versions of >> errno.h, this can result in multiple definitions of EDEADLOCK in the >> include chain. Definitions to the same value (e.g. seen with mips) do >> not raise warnings, but on powerpc there are redefinitions changing the >> value, which raise warnings and errors (if using "-Werror"). >> >> Guard against these redefinitions to avoid build errors like the following, >> first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with >> musl 1.1.24: >> >> In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5, >>from ../../include/linux/err.h:8, >>from libbpf.c:29: >> ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined >> [-Werror] >>#define EDEADLOCK EDEADLK >> >> In file included from >> toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10, >>from libbpf.c:26: >> toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this >> is the location of the previous definition >>#define EDEADLOCK 58 >> >> cc1: all warnings being treated as errors >> >> CC: Stable >> Reported-by: Rosen Penev >> Signed-off-by: Tony Ambardar >> --- >> v1 -> v2: >> * clean up commit description formatting >> >> v2 -> v3: (per Michael Ellerman) >> * drop indeterminate 'Fixes' tags, request stable backports instead >> --- >> arch/powerpc/include/uapi/asm/errno.h | 1 + >> tools/arch/powerpc/include/uapi/asm/errno.h | 1 + >> 2 files changed, 2 insertions(+) >> >> diff --git a/arch/powerpc/include/uapi/asm/errno.h >> b/arch/powerpc/include/uapi/asm/errno.h >> index cc79856896a1..4ba87de32be0 100644 >> --- a/arch/powerpc/include/uapi/asm/errno.h >> +++ b/arch/powerpc/include/uapi/asm/errno.h >> @@ -2,6 +2,7 @@ >> #ifndef _ASM_POWERPC_ERRNO_H >> #define _ASM_POWERPC_ERRNO_H >> >> +#undef EDEADLOCK >> #include >> >> #undef EDEADLOCK >> diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h >> b/tools/arch/powerpc/include/uapi/asm/errno.h >> index cc79856896a1..4ba87de32be0 100644 >> --- a/tools/arch/powerpc/include/uapi/asm/errno.h >> +++ b/tools/arch/powerpc/include/uapi/asm/errno.h >> @@ -2,6 +2,7 @@ >> #ifndef _ASM_POWERPC_ERRNO_H >> #define _ASM_POWERPC_ERRNO_H >> >> +#undef EDEADLOCK >> #include >> >> #undef EDEADLOCK >> -- >> 2.25.1 >>
Re: [PATCH RESEND v1 0/4] powerpc/vdso: Add support for time namespaces
Thomas Gleixner writes: > On Wed, Mar 31 2021 at 16:48, Christophe Leroy wrote: >> [Sorry, resending with complete destination list, I used the wrong script on >> the first delivery] >> >> This series adds support for time namespaces on powerpc. >> >> All timens selftests are successfull. > > If PPC people want to pick up the whole lot, no objections from my side. Thanks, will do. cheers
Re: [PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2
Alex Williamson writes: > On Fri, 26 Mar 2021 07:13:10 +0100 > Christoph Hellwig wrote: > >> This driver never had any open userspace (which for VFIO would include >> VM kernel drivers) that use it, and thus should never have been added >> by our normal userspace ABI rules. >> >> Signed-off-by: Christoph Hellwig >> Acked-by: Greg Kroah-Hartman >> --- >> drivers/vfio/pci/Kconfig| 6 - >> drivers/vfio/pci/Makefile | 1 - >> drivers/vfio/pci/vfio_pci.c | 18 - >> drivers/vfio/pci/vfio_pci_nvlink2.c | 490 >> drivers/vfio/pci/vfio_pci_private.h | 14 - >> include/uapi/linux/vfio.h | 38 +-- >> 6 files changed, 4 insertions(+), 563 deletions(-) >> delete mode 100644 drivers/vfio/pci/vfio_pci_nvlink2.c > > Hearing no objections, applied to vfio next branch for v5.13. Thanks, Looks like you only took patch 1? I can't take patch 2 on its own, that would break the build. Do you want to take both patches? There's currently no conflicts against my tree. It's possible one could appear before the v5.13 merge window, though it would probably just be something minor. Or I could apply both patches to my tree, which means patch 1 would appear as two commits in the git history, but that's not a big deal. cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.12-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.12: The following changes since commit 53f1d31708f6240e4615b0927df31f182e389e2f: powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT (2021-03-26 22:19:39 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.12-6 for you to fetch changes up to 791f9e36599d94af5a76d3f74d04e16326761aae: powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt (2021-04-02 00:18:09 +1100) - -- powerpc fixes for 5.12 #6 Fix an oops triggered by ptrace when CONFIG_PPC_FPU_REGS=n. Fix an oops on sigreturn when the VDSO is unmapped on 32-bit. Fix vdso_wrapper.o not being rebuilt everytime vdso.so is rebuilt. Thanks to Christophe Leroy. - -- Christophe Leroy (3): powerpc/ptrace: Don't return error when getting/setting FP regs without CONFIG_PPC_FPU_REGS powerpc/signal32: Fix Oops on sigreturn with unmapped VDSO powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt arch/powerpc/kernel/Makefile | 4 arch/powerpc/kernel/ptrace/Makefile | 4 ++-- arch/powerpc/kernel/ptrace/ptrace-decl.h | 14 -- arch/powerpc/kernel/ptrace/ptrace-fpu.c | 10 ++ arch/powerpc/kernel/ptrace/ptrace-novsx.c | 8 arch/powerpc/kernel/ptrace/ptrace-view.c | 2 -- arch/powerpc/kernel/signal_32.c | 20 7 files changed, 32 insertions(+), 30 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBxuXYACgkQUevqPMjh pYBgHQ//eM5IN34NKvsdcVEZatYDqIwMNL0w805XmFXcNHeUJ3HP6wf+R84L6zzi 9reylRchDSGOO7qGDbhutDeCvtEO3hgqG+t60sraHEMD8bmzxy3cnidYBpL+SXCV AmI2hpTzv/qhTLLD85Q6A7jtA0QCJA+Qluw2cgWB44XbKsNX4tofXBMxCZC8tvmb /SBb2ccZQ1Q0ZkkQSnxuf/MV1h4m8+sOryc7iIbAlfW3Ag5xEj6UwUzpS8VJ0h/e WR6QRERZN5jwP9jMWVMo7zXw1Rw/vbN97hayUj3dk1QofLmAEOQMG8uPF43SKnAu 3hdabHASC7apYbiN6DQWSh3waXZP5a/pWhMjHKvYEsEOJCxYXTXuI124fbB+QkSj v8VzKzoDCt4rh7H7wsY8lmqDjwrklEtRrdg0qaZ9seMG6+hWv/0iu30x3NLHLSLD pR1rhWRlgVNegT++sQlBdgYory4qrAhi6s+0tXWSEX86XqSNaQd9U3KZ4sBwlnAQ dgaPOQl5T3uY8kVWaSMadMT6IXVetkIBOiUOBUqNzeBKsEPAYj9Hs7FK402cuUT4 O/KwqIeEuDcO6lLCznU81uapqOaGVbsPs/qcETCqyfJmzo8Us/slFmzCd3bvSm+a eIUUUyrgSAi3LjczjnOwjOXj0RId43/hMLkfrT0EZ138wwjHm7s= =2wh+ -END PGP SIGNATURE-
Re: [PATCH v2] powerpc: iommu: fix build when neither PCI or IBMVIO is set
On Sun, 4 Apr 2021 12:26:23 -0700, Randy Dunlap wrote:
> When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a
> build error. The fault injection code is not useful in that kernel config,
> so make the FAIL_IOMMU option depend on PCI || IBMVIO.
>
> Prevents this build error (warning escalated to error):
> ../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier'
> defined but not used [-Werror=unused-variable]
> 178 | static struct notifier_block fail_iommu_bus_notifier = {
Applied to powerpc/next.
[1/1] powerpc: iommu: fix build when neither PCI or IBMVIO is set
https://git.kernel.org/powerpc/c/b27dadecdf9102838331b9a0b41ffc1cfe288154
cheers
Re: [PATCH] powerpc/pseries: remove unneeded semicolon
On Tue, 6 Apr 2021 09:33:05 +0800, Yang Li wrote: > Eliminate the following coccicheck warning: > ./arch/powerpc/platforms/pseries/lpar.c:1633:2-3: Unneeded semicolon Applied to powerpc/next. [1/1] powerpc/pseries: remove unneeded semicolon https://git.kernel.org/powerpc/c/01ed0510941ae1350c501977132bdb54630614e2 cheers
Re: [PATCH v2 0/8] Implement EBPF on powerpc32
On Mon, 22 Mar 2021 16:37:45 + (UTC), Christophe Leroy wrote: > This series implements extended BPF on powerpc32. For the implementation > details, see the patch before the last. > > The following operations are not implemented: > > case BPF_ALU64 | BPF_DIV | BPF_X: /* dst /= src */ > case BPF_ALU64 | BPF_MOD | BPF_X: /* dst %= src */ > case BPF_STX | BPF_XADD | BPF_DW: /* *(u64 *)(dst + off) += src > */ > > [...] Applied to powerpc/next. [1/8] powerpc/bpf: Remove classical BPF support for PPC32 https://git.kernel.org/powerpc/c/6944caad78fc4de4ecd0364bbc9715b62b020965 [2/8] powerpc/bpf: Change register numbering for bpf_set/is_seen_register() https://git.kernel.org/powerpc/c/ed573b57e77a7860fe4026e1700faa2f6938caf1 [3/8] powerpc/bpf: Move common helpers into bpf_jit.h https://git.kernel.org/powerpc/c/f1b1583d5faa86cb3dcb7b740594868debad7c30 [4/8] powerpc/bpf: Move common functions into bpf_jit_comp.c https://git.kernel.org/powerpc/c/4ea76e90a97d22f86adbb10044d29d919e620f2e [5/8] powerpc/bpf: Change values of SEEN_ flags https://git.kernel.org/powerpc/c/c426810fcf9f96e3b43d16039e41ecb959f6dc29 [6/8] powerpc/asm: Add some opcodes in asm/ppc-opcode.h for PPC32 eBPF https://git.kernel.org/powerpc/c/355a8d26cd0416e7e764e4db766cf91e773a03e7 [7/8] powerpc/bpf: Implement extended BPF on PPC32 https://git.kernel.org/powerpc/c/51c66ad849a703d9bbfd7704c941827aed0fd9fd [8/8] powerpc/bpf: Reallocate BPF registers to volatile registers when possible on PPC32 https://git.kernel.org/powerpc/c/40272035e1d0edcd515ad45be297c4cce044536d cheers
Re: [PATCH v3 03/15] powerpc/align: Convert emulate_spe() to user_access_begin
On Fri, 12 Mar 2021 13:25:11 + (UTC), Christophe Leroy wrote:
> This patch converts emulate_spe() to using user_access_begin
> logic.
>
> Since commit 662bbcb2747c ("mm, sched: Allow uaccess in atomic with
> pagefault_disable()"), might_fault() doesn't fire when called from
> sections where pagefaults are disabled, which must be the case
> when using _inatomic variants of __get_user and __put_user. So
> the might_fault() in user_access_begin() is not a problem.
>
> [...]
Applied to powerpc/next.
[03/15] powerpc/align: Convert emulate_spe() to user_access_begin
https://git.kernel.org/powerpc/c/3fa3db32956d74c0784171ae0334685502bb169a
cheers
Re: [PATCH v2 00/15] powerpc: Cleanup of uaccess.h and adding asm goto for get_user()
On Wed, 10 Mar 2021 17:46:39 + (UTC), Christophe Leroy wrote: > This series cleans up uaccess.h and adds asm goto for get_user() > > v2: > - Further clean ups > - asm goto for get_user() > - Move a few patches unrelated to put_user/get_user into another misc series. > > [...] Applied to powerpc/next. [01/15] powerpc/uaccess: Remove __get_user_allowed() and unsafe_op_wrap() https://git.kernel.org/powerpc/c/8cdf748d557f15ae6f9e0d4108cc3ea6e1ee4419 [02/15] powerpc/uaccess: Define ___get_user_instr() for ppc32 https://git.kernel.org/powerpc/c/9bd68dc5d7463cb959bff9ac4b6c7e578171de35 [03/15] powerpc/align: Convert emulate_spe() to user_access_begin https://git.kernel.org/powerpc/c/3fa3db32956d74c0784171ae0334685502bb169a [04/15] powerpc/uaccess: Remove __get/put_user_inatomic() https://git.kernel.org/powerpc/c/bad956b8fe1a8b3b634d596ed2023ec30726cdf1 [05/15] powerpc/uaccess: Move get_user_instr helpers in asm/inst.h https://git.kernel.org/powerpc/c/35506a3e2d7c4d93cb564e23471a448cbd98f085 [06/15] powerpc/align: Don't use __get_user_instr() on kernel addresses https://git.kernel.org/powerpc/c/111631b5e9dae764754657aad00bd6cd1a805d0d [07/15] powerpc/uaccess: Call might_fault() inconditionaly https://git.kernel.org/powerpc/c/ed0d9c66f97c6865e87fa6e3631bbc3919a31ad6 [08/15] powerpc/uaccess: Remove __unsafe_put_user_goto() https://git.kernel.org/powerpc/c/be15a165796598cd3929ca9aac56ba5ec69e41c1 [09/15] powerpc/uaccess: Remove __chk_user_ptr() in __get/put_user https://git.kernel.org/powerpc/c/028e15616857add3ba4951f989027675370b0e82 [10/15] powerpc/uaccess: Remove calls to __get_user_bad() and __put_user_bad() https://git.kernel.org/powerpc/c/9975f852ce1bf041a1a81bf882e29ee7a3b78ca6 [11/15] powerpc/uaccess: Split out __get_user_nocheck() https://git.kernel.org/powerpc/c/f904c22f2a9fb09fe705efdedbe4af9a30bdf633 [12/15] powerpc/uaccess: Rename __get/put_user_check/nocheck https://git.kernel.org/powerpc/c/17f8c0bc21bbb7d1fe729c7f656924a6ea72079b [13/15] powerpc/uaccess: Refactor get/put_user() and __get/put_user() https://git.kernel.org/powerpc/c/e72fcdb26cde72985c418b39f72ecaa222e1f4d5 [14/15] powerpc/uaccess: Introduce __get_user_size_goto() https://git.kernel.org/powerpc/c/035785ab2826beb43cfa65a2df37d60074915a4d [15/15] powerpc/uaccess: Use asm goto for get_user when compiler supports it https://git.kernel.org/powerpc/c/5cd29b1fd3e8f2b45fe6d011588d832417defe31 cheers
Re: [PATCH] powerpc/32: Remove powerpc specific definition of 'ptrdiff_t'
On Mon, 5 Apr 2021 09:57:27 + (UTC), Christophe Leroy wrote:
> For unknown reason, old commit d27dfd388715 ("Import pre2.0.8")
> changed 'ptrdiff_t' from 'int' to 'long'.
>
> GCC expects it as 'int' really, and this leads to the following
> warning when building KFENCE:
>
> CC mm/kfence/report.o
> In file included from ./include/linux/printk.h:7,
> from ./include/linux/kernel.h:16,
> from mm/kfence/report.c:10:
> mm/kfence/report.c: In function 'kfence_report_error':
> ./include/linux/kern_levels.h:5:18: warning: format '%td' expects argument of
> type 'ptrdiff_t', but argument 6 has type 'long int' [-Wformat=]
> 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */
> | ^~
> ./include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
>11 | #define KERN_ERR KERN_SOH "3" /* error conditions */
> | ^~~~
> ./include/linux/printk.h:343:9: note: in expansion of macro 'KERN_ERR'
> 343 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> | ^~~~
> mm/kfence/report.c:213:3: note: in expansion of macro 'pr_err'
> 213 | pr_err("Out-of-bounds %s at 0x%p (%luB %s of kfence-#%td):\n",
> | ^~
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32: Remove powerpc specific definition of 'ptrdiff_t'
https://git.kernel.org/powerpc/c/c46bbf5d2defae50d61ddf31502017ee8952af83
cheers
Re: [PATCH] powerpc: Switch to relative jump labels
On Tue, 23 Mar 2021 15:47:59 + (UTC), Christophe Leroy wrote: > Convert powerpc to relative jump labels. > > Before the patch, pseries_defconfig vmlinux.o has: > 9074 __jump_table 0003f2a0 01321fa8 > 2**0 > > With the patch, the same config gets: > 9074 __jump_table 0002a0e0 01321fb4 > 2**0 > > [...] Applied to powerpc/next. [1/1] powerpc: Switch to relative jump labels https://git.kernel.org/powerpc/c/b0b3b2c78ec075cec4721986a95abbbac8c3da4f cheers
Re: [PATCH 00/10] Convert signal32 to user read access by block
On Fri, 19 Mar 2021 11:06:49 + (UTC), Christophe Leroy wrote:
> Similarly to the work done earlier with writes, this series
> converts signal32 to using user_read_access_begin/end and
> unsafe_get_user() and friends.
>
> Applies on to of the signal64 series, ie on merge-test (ca6e327fefb2)
>
> Christophe Leroy (10):
> signal: Add unsafe_get_compat_sigset()
> powerpc/uaccess: Also perform 64 bits copies in
> unsafe_copy_from_user() on ppc32
> powerpc/signal: Add unsafe_copy_ck{fpr/vsx}_from_user
> powerpc/signal32: Rename save_user_regs_unsafe() and
> save_general_regs_unsafe()
> powerpc/signal32: Remove ifdefery in middle of if/else in sigreturn()
> powerpc/signal32: Perform access_ok() inside restore_user_regs()
> powerpc/signal32: Reorder user reads in restore_tm_user_regs()
> powerpc/signal32: Convert restore_[tm]_user_regs() to user access
> block
> powerpc/signal32: Convert do_setcontext[_tm]() to user access block
> powerpc/signal32: Simplify logging in sigreturn()
>
> [...]
Applied to powerpc/next.
[01/10] signal: Add unsafe_get_compat_sigset()
https://git.kernel.org/powerpc/c/fb05121fd6a20f0830ff2a4420c51af6ca4ac6e7
[02/10] powerpc/uaccess: Also perform 64 bits copies in unsafe_copy_from_user()
on ppc32
https://git.kernel.org/powerpc/c/c1cc1570bc8d94f288060f262f11be8f7672578c
[03/10] powerpc/signal: Add unsafe_copy_ck{fpr/vsx}_from_user
https://git.kernel.org/powerpc/c/7c11f8893a76ac4e86c07f4b57371d5fa593627f
[04/10] powerpc/signal32: Rename save_user_regs_unsafe() and
save_general_regs_unsafe()
https://git.kernel.org/powerpc/c/f918a81e209f24acb45cd935bcfb78d2c024f6a1
[05/10] powerpc/signal32: Remove ifdefery in middle of if/else in sigreturn()
https://git.kernel.org/powerpc/c/ca9e1605cdd9473a0eb4d6da238d2524be12591a
[06/10] powerpc/signal32: Perform access_ok() inside restore_user_regs()
https://git.kernel.org/powerpc/c/362471b3192e4184fff5fedee1ea20bdf637a0c8
[07/10] powerpc/signal32: Reorder user reads in restore_tm_user_regs()
https://git.kernel.org/powerpc/c/036fc2cb1dc2245c2ea7d2f03c7af80417b6310c
[08/10] powerpc/signal32: Convert restore_[tm]_user_regs() to user access block
https://git.kernel.org/powerpc/c/627b72bee84d6652e0af26617e71ce2b3c18fcd5
[09/10] powerpc/signal32: Convert do_setcontext[_tm]() to user access block
https://git.kernel.org/powerpc/c/887f3ceb51cd34109ac17bfc98695162e299e657
[10/10] powerpc/signal32: Simplify logging in sigreturn()
https://git.kernel.org/powerpc/c/c7393a71eb1abdda7e3a3ef798bae60de11540ec
cheers
Re: [PATCH v3] powerpc/traps: Enhance readability for trap types
Christophe Leroy writes:
> Le 08/04/2021 à 16:07, Xiongwei Song a écrit :
>> From: Xiongwei Song
>>
>> Create a new header named traps.h, define macros to list ppc interrupt
>> types in traps.h, replace the reference of the trap hex values with these
>> macros.
...
>> diff --git a/arch/powerpc/include/asm/interrupt.h
>> b/arch/powerpc/include/asm/interrupt.h
>> index 7c633896d758..5ce9898bc9a6 100644
>> --- a/arch/powerpc/include/asm/interrupt.h
>> +++ b/arch/powerpc/include/asm/interrupt.h
>> @@ -8,6 +8,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> struct interrupt_state {
>> #ifdef CONFIG_PPC_BOOK3E_64
>> @@ -59,7 +60,7 @@ static inline void interrupt_enter_prepare(struct pt_regs
>> *regs, struct interrup
>> * CT_WARN_ON comes here via program_check_exception,
>> * so avoid recursion.
>> */
>> -if (TRAP(regs) != 0x700)
>> +if (TRAP(regs) != INTERRUPT_PROGRAM)
>> CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
>> }
>> #endif
>> @@ -156,7 +157,8 @@ static inline void interrupt_nmi_enter_prepare(struct
>> pt_regs *regs, struct inte
>> /* Don't do any per-CPU operations until interrupt state is fixed */
>> #endif
>> /* Allow DEC and PMI to be traced when they are soft-NMI */
>> -if (TRAP(regs) != 0x900 && TRAP(regs) != 0xf00 && TRAP(regs) != 0x260) {
>> +if (TRAP(regs) != INTERRUPT_DECREMENTER &&
>> +TRAP(regs) != INTERRUPT_PERFMON) {
>
> I think too long names hinder readability, see later for suggestions.
I asked for the longer names :)
I think they make it easier for people who are less familiar with the
architecture than us to make sense of the names.
And there's only a couple of cases where it requires splitting a line,
and they could be converted to use switch if we think it's a problem.
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index 0c0b1c2cfb49..641b3feef7ee 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -588,20 +589,24 @@ void __bad_page_fault(struct pt_regs *regs, int sig)
>> /* kernel has accessed a bad area */
>>
>> switch (TRAP(regs)) {
>> -case 0x300:
>> -case 0x380:
>> -case 0xe00:
>> +case INTERRUPT_DATA_STORAGE:
>> +#ifdef CONFIG_PPC_BOOK3S
>> +case INTERRUPT_DATA_SEGMENT:
>> +case INTERRUPT_H_DATA_STORAGE:
>> +#endif
>
> It would be better to avoid #ifdefs when none where necessary before.
Yes I agree.
I think these can all be avoided by defining most of the values
regardless of what platform we're building for. Only the values that
overlap need to be kept behind an ifdef.
cheers
Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
Leonardo Bras writes: > On Thu, 2021-04-08 at 03:20 -0300, Leonardo Bras wrote: >> > > +#define QUERY_DDW_PGSIZE_4K 0x01 >> > > +#define QUERY_DDW_PGSIZE_64K0x02 >> > > +#define QUERY_DDW_PGSIZE_16M0x04 >> > > +#define QUERY_DDW_PGSIZE_32M0x08 >> > > +#define QUERY_DDW_PGSIZE_64M0x10 >> > > +#define QUERY_DDW_PGSIZE_128M 0x20 >> > > +#define QUERY_DDW_PGSIZE_256M 0x40 >> > > +#define QUERY_DDW_PGSIZE_16G0x80 >> > >> > I'm not sure the #defines really gain us much vs just putting the >> > literal values in the array below? >> >> My v1 did not use the define approach, what do you think of that? >> http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210322190943.715368-1-leobra...@gmail.com/ >> >> > (of course, it would be that without the pageshift defines also, using > the __builtin_ctz() approach suggested by Alexey.) Yeah I think I like that better. cheers
Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
Alexey Kardashevskiy writes:
> On 08/04/2021 15:37, Michael Ellerman wrote:
>> Leonardo Bras writes:
>>> According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
>>> will let the OS know all possible pagesizes that can be used for creating a
>>> new DDW.
>>>
>>> Currently Linux will only try using 3 of the 8 available options:
>>> 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M,
>>> 128M, 256M and 16G.
>>
>> Do we know of any hardware & hypervisor combination that will actually
>> give us bigger pages?
>
>
> On P8 16MB host pages and 16MB hardware iommu pages worked.
>
> On P9, VM's 16MB IOMMU pages worked on top of 2MB host pages + 2MB
> hardware IOMMU pages.
The current code already tries 16MB though.
I'm wondering if we're going to ask for larger sizes that have never
been tested and possibly expose bugs. But it sounds like this is mainly
targeted at future platforms.
>>> diff --git a/arch/powerpc/platforms/pseries/iommu.c
>>> b/arch/powerpc/platforms/pseries/iommu.c
>>> index 9fc5217f0c8e..6cda1c92597d 100644
>>> --- a/arch/powerpc/platforms/pseries/iommu.c
>>> +++ b/arch/powerpc/platforms/pseries/iommu.c
>>> @@ -53,6 +53,20 @@ enum {
>>> DDW_EXT_QUERY_OUT_SIZE = 2
>>> };
>>
>> A comment saying where the values come from would be good.
>>
>>> +#define QUERY_DDW_PGSIZE_4K0x01
>>> +#define QUERY_DDW_PGSIZE_64K 0x02
>>> +#define QUERY_DDW_PGSIZE_16M 0x04
>>> +#define QUERY_DDW_PGSIZE_32M 0x08
>>> +#define QUERY_DDW_PGSIZE_64M 0x10
>>> +#define QUERY_DDW_PGSIZE_128M 0x20
>>> +#define QUERY_DDW_PGSIZE_256M 0x40
>>> +#define QUERY_DDW_PGSIZE_16G 0x80
>>
>> I'm not sure the #defines really gain us much vs just putting the
>> literal values in the array below?
>
> Then someone says "u magic values" :) I do not mind either way. Thanks,
Yeah that's true. But #defining them doesn't make them less magic, if
you only use them in one place :)
cheers
Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
Leonardo Bras writes:
> According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
> will let the OS know all possible pagesizes that can be used for creating a
> new DDW.
>
> Currently Linux will only try using 3 of the 8 available options:
> 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M,
> 128M, 256M and 16G.
Do we know of any hardware & hypervisor combination that will actually
give us bigger pages?
> Enabling bigger pages would be interesting for direct mapping systems
> with a lot of RAM, while using less TCE entries.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 49 ++
> 1 file changed, 42 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 9fc5217f0c8e..6cda1c92597d 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -53,6 +53,20 @@ enum {
> DDW_EXT_QUERY_OUT_SIZE = 2
> };
A comment saying where the values come from would be good.
> +#define QUERY_DDW_PGSIZE_4K 0x01
> +#define QUERY_DDW_PGSIZE_64K 0x02
> +#define QUERY_DDW_PGSIZE_16M 0x04
> +#define QUERY_DDW_PGSIZE_32M 0x08
> +#define QUERY_DDW_PGSIZE_64M 0x10
> +#define QUERY_DDW_PGSIZE_128M0x20
> +#define QUERY_DDW_PGSIZE_256M0x40
> +#define QUERY_DDW_PGSIZE_16G 0x80
I'm not sure the #defines really gain us much vs just putting the
literal values in the array below?
> +struct iommu_ddw_pagesize {
> + u32 mask;
> + int shift;
> +};
> +
> static struct iommu_table_group *iommu_pseries_alloc_group(int node)
> {
> struct iommu_table_group *table_group;
> @@ -1099,6 +1113,31 @@ static void reset_dma_window(struct pci_dev *dev,
> struct device_node *par_dn)
>ret);
> }
>
> +/* Returns page shift based on "IO Page Sizes" output at
> ibm,query-pe-dma-window. See LoPAR */
> +static int iommu_get_page_shift(u32 query_page_size)
> +{
> + const struct iommu_ddw_pagesize ddw_pagesize[] = {
> + { QUERY_DDW_PGSIZE_16G, __builtin_ctz(SZ_16G) },
> + { QUERY_DDW_PGSIZE_256M, __builtin_ctz(SZ_256M) },
> + { QUERY_DDW_PGSIZE_128M, __builtin_ctz(SZ_128M) },
> + { QUERY_DDW_PGSIZE_64M, __builtin_ctz(SZ_64M) },
> + { QUERY_DDW_PGSIZE_32M, __builtin_ctz(SZ_32M) },
> + { QUERY_DDW_PGSIZE_16M, __builtin_ctz(SZ_16M) },
> + { QUERY_DDW_PGSIZE_64K, __builtin_ctz(SZ_64K) },
> + { QUERY_DDW_PGSIZE_4K, __builtin_ctz(SZ_4K) }
> + };
cheers
Re: [PATCH] powerpc/dts: fix not include DTC_FLAGS
Youlin Song writes:
> I wanted to build the fsl dts in my machine and found that
> the dtb have not extra space,so uboot will cause about
> FDT_ERR_NOSPACE issue.
>
> Signed-off-by: Youlin Song
> ---
> arch/powerpc/boot/dts/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/boot/dts/Makefile b/arch/powerpc/boot/dts/Makefile
> index fb335d05aae8..c21165c0cd76 100644
> --- a/arch/powerpc/boot/dts/Makefile
> +++ b/arch/powerpc/boot/dts/Makefile
> @@ -2,5 +2,6 @@
>
> subdir-y += fsl
>
> +DTC_FLAGS ?= -p 1024
> dtstree := $(srctree)/$(src)
> dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard
> $(dtstree)/*.dts))
I guess that was missed in 1acf1cf8638a ("powerpc: build .dtb files in dts
directory").
Which I think means the assignment to DTC_FLAGS in
arch/powerpc/boot/Makefile is not needed anymore.
Can you send a v2 removing that assignment and explaining that's what
happened?
cheers
Re: [PATCH v2] powerpc/signal32: Fix Oops on sigreturn with unmapped VDSO
On Wed, 31 Mar 2021 14:07:04 + (UTC), Christophe Leroy wrote: > PPC32 encounters a KUAP fault when trying to handle a signal with > VDSO unmapped. > > Kernel attempted to read user page (7fc07ec0) - exploit attempt? (uid: > 0) > BUG: Unable to handle kernel data access on read at 0x7fc07ec0 > Faulting instruction address: 0xc00111d4 > Oops: Kernel access of bad area, sig: 11 [#1] > BE PAGE_SIZE=16K PREEMPT CMPC885 > CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted > 5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814 > NIP: c00111d4 LR: c0005a28 CTR: > REGS: cadb3dd0 TRAP: 0300 Not tainted > (5.12.0-rc4-s3k-dev-01553-gb30c310ea220) > MSR: 9032 CR: 48000884 XER: 2000 > DAR: 7fc07ec0 DSISR: 8800 > GPR00: c0007788 cadb3e90 c28d4a40 7fc07ec0 7fc07ed0 04e0 7fc07ce0 > > GPR08: 0001 0001 7fc07ec0 28000282 1001b828 100a0920 > > GPR16: 100cac0c 100b 105c43a4 105c5685 100d 100d 100d > 100b2e9e > GPR24: 105c43c8 7fc07ec8 cadb3f40 cadb3ec8 c28d4a40 > > NIP [c00111d4] flush_icache_range+0x90/0xb4 > LR [c0005a28] handle_signal32+0x1bc/0x1c4 > Call Trace: > [cadb3e90] [100d] 0x100d (unreliable) > [cadb3ec0] [c0007788] do_notify_resume+0x260/0x314 > [cadb3f20] [c000c764] syscall_exit_prepare+0x120/0x184 > [cadb3f30] [c00100b4] ret_from_syscall+0xc/0x28 > --- interrupt: c00 at 0xfe807f8 > NIP: 0fe807f8 LR: 10001060 CTR: c0139378 > REGS: cadb3f40 TRAP: 0c00 Not tainted > (5.12.0-rc4-s3k-dev-01553-gb30c310ea220) > MSR: d032 CR: 28000482 XER: 2000 > > [...] Applied to powerpc/fixes. [1/1] powerpc/signal32: Fix Oops on sigreturn with unmapped VDSO https://git.kernel.org/powerpc/c/acca57217c688c5bbbd5140974533d81e8757cc9 cheers
Re: [PATCH] powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt
On Wed, 31 Mar 2021 09:12:19 + (UTC), Christophe Leroy wrote:
> Commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of
> vgettimeofday.o") moved vdso32_wrapper.o and vdso64_wrapper.o out
> of arch/powerpc/kernel/vdso[32/64]/ and removed the dependencies in
> the Makefile. This leads to the wrappers not being re-build hence the
> kernel embedding the old vdso library.
>
> Add back missing dependencies to ensure vdso32_wrapper.o and vdso64_wrapper.o
> are rebuilt when vdso32.so.dbg and vdso64.so.dbg are changed.
Applied to powerpc/fixes.
[1/1] powerpc/vdso: Make sure vdso_wrapper.o is rebuilt everytime vdso.so is
rebuilt
https://git.kernel.org/powerpc/c/791f9e36599d94af5a76d3f74d04e16326761aae
cheers
Re: [PATCH] powerpc/ptrace: Don't return error when getting/setting FP regs without CONFIG_PPC_FPU_REGS
On Wed, 31 Mar 2021 14:14:58 + (UTC), Christophe Leroy wrote: > An #ifdef CONFIG_PPC_FPU_REGS is missing in arch_ptrace() leading > to the following Oops because [REGSET_FPR] entry is not initialised in > native_regsets[]. > > [ 41.917608] BUG: Unable to handle kernel instruction fetch > [ 41.922849] Faulting instruction address: 0xff8fd228 > [ 41.927760] Oops: Kernel access of bad area, sig: 11 [#1] > [ 41.933089] BE PAGE_SIZE=4K PREEMPT CMPC885 > [ 41.940753] Modules linked in: > [ 41.943768] CPU: 0 PID: 366 Comm: gdb Not tainted > 5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty #4835 > [ 41.952800] NIP: ff8fd228 LR: c004d9e0 CTR: ff8fd228 > [ 41.957790] REGS: caae9df0 TRAP: 0400 Not tainted > (5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty) > [ 41.966741] MSR: 40009032 CR: 82004248 XER: 2000 > [ 41.973540] > [ 41.973540] GPR00: c004d9b4 caae9eb0 c1b64f60 c1b64520 c0713cd4 caae9eb8 > c1bacdfc 0004 > [ 41.973540] GPR08: 0200 ff8fd228 c1bac700 1032 28004242 1061aaf4 > 0001 106d64a0 > [ 41.973540] GPR16: 7fa0a774 1061 7fa0aef9 > 1061 7fa0a538 > [ 41.973540] GPR24: 7fa0a580 7fa0a570 c1bacc00 c1b64520 c1bacc00 caae9ee8 > 0108 c0713cd4 > [ 42.009685] NIP [ff8fd228] 0xff8fd228 > [ 42.013300] LR [c004d9e0] __regset_get+0x100/0x124 > [ 42.018036] Call Trace: > [ 42.020443] [caae9eb0] [c004d9b4] __regset_get+0xd4/0x124 (unreliable) > [ 42.026899] [caae9ee0] [c004da94] copy_regset_to_user+0x5c/0xb0 > [ 42.032751] [caae9f10] [c002f640] sys_ptrace+0xe4/0x588 > [ 42.037915] [caae9f30] [c0011010] ret_from_syscall+0x0/0x28 > [ 42.043422] --- interrupt: c00 at 0xfd1f8e4 > [ 42.047553] NIP: 0fd1f8e4 LR: 1004a688 CTR: > [ 42.052544] REGS: caae9f40 TRAP: 0c00 Not tainted > (5.12.0-rc5-s3k-dev-01666-g7aac86a0f057-dirty) > [ 42.061494] MSR: d032 CR: 48004442 XER: > [ 42.068551] > [ 42.068551] GPR00: 001a 7fa0a040 77dad7e0 000e 0170 > 7fa0a078 0004 > [ 42.068551] GPR08: 108deb88 108dda40 106d6010 44004442 1061aaf4 > 0001 106d64a0 > [ 42.068551] GPR16: 7fa0a774 1061 7fa0aef9 > 1061 7fa0a538 > [ 42.068551] GPR24: 7fa0a580 7fa0a570 1078fe00 1078fd70 1078fd70 0170 > 0fdd3244 000d > [ 42.104696] NIP [0fd1f8e4] 0xfd1f8e4 > [ 42.108225] LR [1004a688] 0x1004a688 > [ 42.111753] --- interrupt: c00 > [ 42.114768] Instruction dump: > [ 42.117698] > > [ 42.125443] > > [ 42.133195] ---[ end trace d35616f22ab2100c ]--- > > [...] Applied to powerpc/fixes. [1/1] powerpc/ptrace: Don't return error when getting/setting FP regs without CONFIG_PPC_FPU_REGS https://git.kernel.org/powerpc/c/3618250c8399cb36f4a0fbc48610a178307e1c64 cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.12-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.12: The following changes since commit cc7a0bb058b85ea03db87169c60c7cfdd5d34678: PCI: rpadlpar: Fix potential drc_name corruption in store functions (2021-03-17 13:48:07 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.12-5 for you to fetch changes up to 53f1d31708f6240e4615b0927df31f182e389e2f: powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT (2021-03-26 22:19:39 +1100) - -- powerpc fixes for 5.12 #5 Fix a bug on pseries where spurious wakeups from H_PROD would prevent partition migration from succeeding. Fix oopses seen in pcpu_alloc(), caused by parallel faults of the percpu mapping causing us to corrupt the protection key used for the mapping, and cause a fatal key fault. Thanks to Aneesh Kumar K.V, Murilo Opsfelder Araujo, Nathan Lynch. - -- Aneesh Kumar K.V (1): powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT Nathan Lynch (2): powerpc/pseries/mobility: use struct for shared state powerpc/pseries/mobility: handle premature return from H_JOIN arch/powerpc/platforms/pseries/lpar.c | 3 +- arch/powerpc/platforms/pseries/mobility.c | 48 ++-- 2 files changed, 46 insertions(+), 5 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBoVTsACgkQUevqPMjh pYDlFxAAkkiy2RiHbaAlWHpVekXVQN1/oRISHQ+9jRco3BQUAEq8wHJNrlArnab6 N7C/ig2SiugagpLelRsXeXWyM54U3syIQnX3NRg82PgUBxU/LGJmIcyWCgDIf9x0 /xbMrWcRMuzY1x916rX7MPuSVc8LcyVu9nByBrbFWNE6IqUrJ0ngrBNNsEyWbEf/ NBHYqUzpurXYv/OHEPOQu9GIOWej5SR8oOKGn3/aJ66cg3WoC7iC56seBjSIrcLe zwhUenwRYM6YQ6boX0OBKs/NaPSeT9qy4JyZOe0Sqeo0Yvhj4VJs9W0napIYQde5 y6ieoyHk33xPawUWiTEtkLmvH2nZPVRXCfGOQmh5B4mvuS/rrv6hTeFkdLFZ74yJ Fuan/ljnXSPTkT+xRITrOO/irZyTaRXJ4j0Ck3LrtluUFib9psf+OqtoIiqqy11w u+E8T1GChRZTuy2iMZy1jiyvmKwa/S5v67YUU2xUXNYeRI8j3g3cPo/W9Skn3TS2 LiO5+/6Ws1ABn7TohGV2R7sTPu5AnJP7jyHVJuDbtf/Z79U1SMiNAOb8jA/8WNbW 0NtLSQsy1PHonsqUIJgJntmstA46Xnsr1ruA2wR7GEuaaBrjSynw9cG55KlA4Lug 16kaOFPBnJhvkgjTDI7Xl7+ktr4yuR5EriDI0wJMqbhxn+IJ5VM= =9cfb -END PGP SIGNATURE-
Re: [PATCH] powerpc/8xx: Load modules closer to kernel text
Christophe Leroy writes: > Le 31/03/2021 à 15:39, Michael Ellerman a écrit : >> Christophe Leroy writes: >>> On the 8xx, TASK_SIZE is 0x8000. The space between TASK_SIZE and >>> PAGE_OFFSET is not used. >>> >>> Use it to load modules in order to minimise the distance between >>> kernel text and modules and avoid trampolines in modules to access >>> kernel functions or other module functions. >>> >>> Define a 16Mbytes area for modules, that's more than enough. >> >> 16MB seems kind of small. >> >> At least on 64-bit we could potentially have hundreds of MBs of modules. >> > > Well, with a 16 MB kernel and 16 MB modules, my board is full :) Heh. > Even on the more recent board that has 128 MB, I don't expect more than a few > MBs of modules in > addition to the kernel which is approx 8M. > > But ok, I'll do something more generic, though it will conflict with Jordan's > series. Don't feel you have to. You're the expert on 8xx, not me. cheers
Re: [PATCH v2] powerpc/traps: Enhance readability for trap types
Segher Boessenkool writes: > On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote: >> So perhaps: >> >> EXC_SYSTEM_RESET >> EXC_MACHINE_CHECK >> EXC_DATA_STORAGE >> EXC_DATA_SEGMENT >> EXC_INST_STORAGE >> EXC_INST_SEGMENT >> EXC_EXTERNAL_INTERRUPT >> EXC_ALIGNMENT >> EXC_PROGRAM_CHECK >> EXC_FP_UNAVAILABLE >> EXC_DECREMENTER >> EXC_HV_DECREMENTER >> EXC_SYSTEM_CALL >> EXC_HV_DATA_STORAGE >> EXC_PERF_MONITOR > > These are interrupt (vectors), not exceptions. It doesn't matter all > that much, but confusing things more isn't useful either! There can be > multiple exceptions that all can trigger the same interrupt. Yeah I know, but I think that ship has already sailed as far as the naming we have in the kernel. We have over 250 uses of "exc", and several files called "exception" something. Using "interrupt" can also be confusing because Linux uses that to mean "external interrupt". But I dunno, maybe INT or VEC is clearer? .. or TRAP :) cheers
Re: [PATCH] powerpc/8xx: Load modules closer to kernel text
Christophe Leroy writes: > On the 8xx, TASK_SIZE is 0x8000. The space between TASK_SIZE and > PAGE_OFFSET is not used. > > Use it to load modules in order to minimise the distance between > kernel text and modules and avoid trampolines in modules to access > kernel functions or other module functions. > > Define a 16Mbytes area for modules, that's more than enough. 16MB seems kind of small. At least on 64-bit we could potentially have hundreds of MBs of modules. cheers
Re: [PATCH] powerpc/signal32: Fix Oops on sigreturn with unmapped VDSO
Christophe Leroy writes:
> PPC32 encounters a KUAP fault when trying to handle a signal with
> VDSO unmapped.
>
> Kernel attempted to read user page (7fc07ec0) - exploit attempt? (uid:
> 0)
> BUG: Unable to handle kernel data access on read at 0x7fc07ec0
> Faulting instruction address: 0xc00111d4
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=16K PREEMPT CMPC885
> CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted
> 5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814
> NIP: c00111d4 LR: c0005a28 CTR:
> REGS: cadb3dd0 TRAP: 0300 Not tainted
> (5.12.0-rc4-s3k-dev-01553-gb30c310ea220)
> MSR: 9032 CR: 48000884 XER: 2000
> DAR: 7fc07ec0 DSISR: 8800
> GPR00: c0007788 cadb3e90 c28d4a40 7fc07ec0 7fc07ed0 04e0 7fc07ce0
>
> GPR08: 0001 0001 7fc07ec0 28000282 1001b828 100a0920
>
> GPR16: 100cac0c 100b 105c43a4 105c5685 100d 100d 100d
> 100b2e9e
> GPR24: 105c43c8 7fc07ec8 cadb3f40 cadb3ec8 c28d4a40
>
> NIP [c00111d4] flush_icache_range+0x90/0xb4
> LR [c0005a28] handle_signal32+0x1bc/0x1c4
> Call Trace:
> [cadb3e90] [100d] 0x100d (unreliable)
> [cadb3ec0] [c0007788] do_notify_resume+0x260/0x314
> [cadb3f20] [c000c764] syscall_exit_prepare+0x120/0x184
> [cadb3f30] [c00100b4] ret_from_syscall+0xc/0x28
> --- interrupt: c00 at 0xfe807f8
> NIP: 0fe807f8 LR: 10001060 CTR: c0139378
> REGS: cadb3f40 TRAP: 0c00 Not tainted
> (5.12.0-rc4-s3k-dev-01553-gb30c310ea220)
> MSR: d032 CR: 28000482 XER: 2000
>
> GPR00: 0025 7fc081c0 77bb1690 000a 28000482 0001
> 0ff03a38
> GPR08: d032 6de5 c28d4a40 0009 88000482 1001b828 100a0920
>
> GPR16: 100cac0c 100b 105c43a4 105c5685 100d 100d 100d
> 100b2e9e
> GPR24: 105c43c8 77ba7628 10002398 1001 10002124
> 00024000
> NIP [0fe807f8] 0xfe807f8
> LR [10001060] 0x10001060
> --- interrupt: c00
> Instruction dump:
> 38630010 7c001fac 38630010 4200fff0 7c0004ac 4c00012c 4e800020 7c001fac
> 2c0a 38630010 4082ffcc 4be4 <7c00186c> 2c07 39430010
> 4082ff8c
> ---[ end trace 3973fb72b049cb06 ]---
>
> This is because flush_icache_range() is called on user addresses.
>
> The same problem was detected some time ago on PPC64. It was fixed by
> enabling KUAP in commit 59bee45b9712 ("powerpc/mm: Fix missing KUAP
> disable in flush_coherent_icache()").
>
> PPC32 doesn't use flush_coherent_icache() and fallbacks on
> clean_dcache_range() and invalidate_icache_range().
But this code is also used for compat tasks on 64-bit.
> We could fix it similarly by enabling user access in those functions,
> but this is overkill for just flushing two instructions.
>
> The two instructions are 8 bytes aligned, so a single dcbst/icbi is
> enough to flush them. Do like __patch_instruction() and inline
> a dcbst followed by an icbi just after the write of the instructions,
> while user access is still allowed. The isync is not required because
> rfi will be used to return to user.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/signal_32.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
> index 75ee918a120a..5b2ba2731957 100644
> --- a/arch/powerpc/kernel/signal_32.c
> +++ b/arch/powerpc/kernel/signal_32.c
> @@ -809,6 +809,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t
> *oldset,
> unsafe_put_user(PPC_INST_ADDI + __NR_rt_sigreturn,
> >mc_pad[0],
> failed);
> unsafe_put_user(PPC_INST_SC, >mc_pad[1], failed);
> + asm("dcbst %y0; sync; icbi %y0; sync" :: "Z" (mctx->mc_pad[0]));
If I'm reading that right you're pointing the icbi at the user address.
That's going to cause a KUAP fault just like we fixed in commit
59bee45b9712 ("powerpc/mm: Fix missing KUAP disable in
flush_coherent_icache()").
We have user write access enabled, but the icbi is treated as a load.
So I don't think that's going to work.
cheers
Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
Christophe Leroy writes:
> Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
>> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
>> VVAR page is in front of the VDSO area. In result it breaks CRIU
>> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
>> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
>> Laurent made a patch to keep CRIU working (by reading aux vector).
>> But I think it still makes sence to separate two mappings into different
>> VMAs. It will also make ppc64 less "special" for userspace and as
>> a side-bonus will make VVAR page un-writable by debugger (which previously
>> would COW page and can be unexpected).
>>
>> I opportunistically Cc stable on it: I understand that usually such
>> stuff isn't a stable material, but that will allow us in CRIU have
>> one workaround less that is needed just for one release (v5.11) on
>> one platform (ppc64), which we otherwise have to maintain.
>> I wouldn't go as far as to say that the commit 511157ab641e is ABI
>> regression as no other userspace got broken, but I'd really appreciate
>> if it gets backported to v5.11 after v5.12 is released, so as not
>> to complicate already non-simple CRIU-vdso code. Thanks!
>>
>> Cc: Andrei Vagin
>> Cc: Andy Lutomirski
>> Cc: Benjamin Herrenschmidt
>> Cc: Christophe Leroy
>> Cc: Laurent Dufour
>> Cc: Michael Ellerman
>> Cc: Paul Mackerras
>> Cc: linuxppc-...@lists.ozlabs.org
>> Cc: sta...@vger.kernel.org # v5.11
>> [1]: https://github.com/checkpoint-restore/criu/issues/1417
>> Signed-off-by: Dmitry Safonov
>> Tested-by: Christophe Leroy
>> ---
>> arch/powerpc/include/asm/mmu_context.h | 2 +-
>> arch/powerpc/kernel/vdso.c | 54 +++---
>> 2 files changed, 40 insertions(+), 16 deletions(-)
>>
>
>> @@ -133,7 +135,13 @@ static int __arch_setup_additional_pages(struct
>> linux_binprm *bprm, int uses_int
>> * install_special_mapping or the perf counter mmap tracking code
>> * will fail to recognise it as a vDSO.
>> */
>> -mm->context.vdso = (void __user *)vdso_base + PAGE_SIZE;
>> +mm->context.vdso = (void __user *)vdso_base + vvar_size;
>> +
>> +vma = _install_special_mapping(mm, vdso_base, vvar_size,
>> + VM_READ | VM_MAYREAD | VM_IO |
>> + VM_DONTDUMP | VM_PFNMAP, _spec);
>> +if (IS_ERR(vma))
>> +return PTR_ERR(vma);
>>
>> /*
>> * our vma flags don't have VM_WRITE so by default, the process isn't
>
>
> IIUC, VM_PFNMAP is for when we have a vvar_fault handler.
Some of the other flags seem odd too.
eg. VM_IO ? VM_DONTDUMP ?
cheers
Re: [PATCH v2] powerpc/traps: Enhance readability for trap types
Xiongwei Song writes: > From: Xiongwei Song > > Create a new header named traps.h, define macros to list ppc exception > types in traps.h, replace the reference of the real trap values with > these macros. Personally I find the hex values easier to recognise, but I realise that's probably not true of other people :) ... > diff --git a/arch/powerpc/include/asm/traps.h > b/arch/powerpc/include/asm/traps.h > new file mode 100644 > index ..a31b6122de23 > --- /dev/null > +++ b/arch/powerpc/include/asm/traps.h > @@ -0,0 +1,19 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_PPC_TRAPS_H > +#define _ASM_PPC_TRAPS_H > + > +#define TRAP_RESET 0x100 /* System reset */ > +#define TRAP_MCE 0x200 /* Machine check */ > +#define TRAP_DSI 0x300 /* Data storage */ > +#define TRAP_DSEGI 0x380 /* Data segment */ > +#define TRAP_ISI 0x400 /* Instruction storage */ > +#define TRAP_ISEGI 0x480 /* Instruction segment */ > +#define TRAP_ALIGN 0x600 /* Alignment */ > +#define TRAP_PROG0x700 /* Program */ > +#define TRAP_DEC 0x900 /* Decrementer */ > +#define TRAP_SYSCALL 0xc00 /* System call */ > +#define TRAP_TRACEI 0xd00 /* Trace */ > +#define TRAP_FPA 0xe00 /* Floating-point Assist */ > +#define TRAP_PMI 0xf00 /* Performance monitor */ I know the macro is called TRAP and the field in pt_regs is called trap, but the terminology in the architecture is "exception", and we already have many uses of that. In particular we have a lot of uses of "exc" as an abbreviation for "exception". So I think I'd rather we use that than "TRAP". I think we should probably use the names from the ISA, unless they are really over long. Which are: 0x100 System Reset 0x200 Machine Check 0x300 Data Storage 0x380 Data Segment 0x400 Instruction Storage 0x480 Instruction Segment 0x500 External 0x600 Alignment 0x700 Program 0x800 Floating-Point Unavailable 0x900 Decrementer 0x980 Hypervisor Decrementer 0xA00 Directed Privileged Doorbell 0xC00 System Call 0xD00 Trace 0xE00 Hypervisor Data Storage 0xE20 Hypervisor Instruction Storage 0xE40 Hypervisor Emulation Assistance 0xE60 Hypervisor Maintenance 0xE80 Directed Hypervisor Doorbell 0xEA0 Hypervisor Virtualization 0xF00 Performance Monitor 0xF20 Vector Unavailable 0xF40 VSX Unavailable 0xF60 Facility Unavailable 0xF80 Hypervisor Facility Unavailable 0xFA0 Directed Ultravisor Doorbell So perhaps: EXC_SYSTEM_RESET EXC_MACHINE_CHECK EXC_DATA_STORAGE EXC_DATA_SEGMENT EXC_INST_STORAGE EXC_INST_SEGMENT EXC_EXTERNAL_INTERRUPT EXC_ALIGNMENT EXC_PROGRAM_CHECK EXC_FP_UNAVAILABLE EXC_DECREMENTER EXC_HV_DECREMENTER EXC_SYSTEM_CALL EXC_HV_DATA_STORAGE EXC_PERF_MONITOR cheers
Re: [PATCH] powerpc: kernel: Trivial spelling fixes throughout the file head_fsl_booke.S
On Mon, 15 Mar 2021 03:34:36 +0530, Bhaskar Chowdhury wrote: > Trivial spelling fixes throughout the file. Applied to powerpc/next. [1/1] powerpc: kernel: Trivial spelling fixes throughout the file head_fsl_booke.S https://git.kernel.org/powerpc/c/f239873fcd953557ba9a9781d10ca95c0594e2b3 cheers
Re: [PATCH] powerpc/xive: use true and false for bool variable
On Mon, 15 Mar 2021 15:24:56 +0800, Yang Li wrote: > fixed the following coccicheck: > ./arch/powerpc/sysdev/xive/spapr.c:552:8-9: WARNING: return of 0/1 in > function 'xive_spapr_match' with return type bool Applied to powerpc/next. [1/1] powerpc/xive: use true and false for bool variable https://git.kernel.org/powerpc/c/9214cf0f48cac3c6aa86f34e14969b5eccb72fad cheers
Re: [PATCH] arch: powerpc: kernel: Change droping to dropping in the file traps.c
On Wed, 24 Feb 2021 13:25:47 +0530, Bhaskar Chowdhury wrote: > s/droping/dropping/ Applied to powerpc/next. [1/1] arch: powerpc: kernel: Change droping to dropping in the file traps.c https://git.kernel.org/powerpc/c/5c4a4802b9ac8c1acdf2250fad3f8f2d6254f9c7 cheers
Re: [PATCH] cxl: Fix couple of spellings
On Mon, 22 Mar 2021 08:03:07 +0530, Bhaskar Chowdhury wrote: > s/filesytem/filesystem/ > s/symantics/semantics/ Applied to powerpc/next. [1/1] cxl: Fix couple of spellings https://git.kernel.org/powerpc/c/e23ecdf9fd87c547a3ac55bcebaf7df28df2fab0 cheers
Re: [PATCH] powerpc: mm: book3s64: Fix a typo in the file mmu_context.c
On Fri, 12 Mar 2021 16:55:37 +0530, Bhaskar Chowdhury wrote: > s/detalis/details/ Applied to powerpc/next. [1/1] powerpc: mm: book3s64: Fix a typo in the file mmu_context.c https://git.kernel.org/powerpc/c/7a7d744ffe87ae10ab98004d1a6ca1f691af58e1 cheers
Re: [PATCH] powerpc/prom: Mark identical_pvr_fixup as __init
On Tue, 2 Mar 2021 13:08:29 -0700, Nathan Chancellor wrote: > If identical_pvr_fixup() is not inlined, there are two modpost warnings: > > WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference > from the function identical_pvr_fixup() to the function > .init.text:of_get_flat_dt_prop() > The function identical_pvr_fixup() references > the function __init of_get_flat_dt_prop(). > This is often because identical_pvr_fixup lacks a __init > annotation or the annotation of of_get_flat_dt_prop is wrong. > > [...] Applied to powerpc/next. [1/1] powerpc/prom: Mark identical_pvr_fixup as __init https://git.kernel.org/powerpc/c/1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc cheers
Re: [PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
On Wed, 17 Mar 2021 14:34:13 +0530, Bhaskar Chowdhury wrote: > s/procesing/processing/ Applied to powerpc/next. [1/1] powerpc: kernel: Trivial typo fix in the file kgdb.c https://git.kernel.org/powerpc/c/89f7d2927ae16ea470d29234447763826e40c6cf cheers
Re: [PATCH v5] powerpc/uprobes: Validation for prefixed instruction
On Thu, 11 Mar 2021 14:45:38 +0530, Ravi Bangoria wrote: > As per ISA 3.1, prefixed instruction should not cross 64-byte > boundary. So don't allow Uprobe on such prefixed instruction. > > There are two ways probed instruction is changed in mapped pages. > First, when Uprobe is activated, it searches for all the relevant > pages and replace instruction in them. In this case, if that probe > is on the 64-byte unaligned prefixed instruction, error out > directly. Second, when Uprobe is already active and user maps a > relevant page via mmap(), instruction is replaced via mmap() code > path. But because Uprobe is invalid, entire mmap() operation can > not be stopped. In this case just print an error and continue. Applied to powerpc/next. [1/1] powerpc/uprobes: Validation for prefixed instruction https://git.kernel.org/powerpc/c/d943bc742a6aabc578b6b62a713ceedf8bf16623 cheers
Re: [PATCH] selftests: powerpc: unmark non-kernel-doc comments
On Thu, 25 Mar 2021 13:08:20 -0700, Randy Dunlap wrote: > Drop the 'beginning of kernel-doc' notation markers (/**) > in places that are not in kernel-doc format. Applied to powerpc/next. [1/1] selftests: powerpc: unmark non-kernel-doc comments https://git.kernel.org/powerpc/c/dfc4ae3372182a168146745def03d877f31fcf2f cheers
Re: [PATCH] powerpc/fadump: Mark fadump_calculate_reserve_size as __init
On Tue, 2 Mar 2021 12:50:14 -0700, Nathan Chancellor wrote: > If fadump_calculate_reserve_size() is not inlined, there is a modpost > warning: > > WARNING: modpost: vmlinux.o(.text+0x5196c): Section mismatch in > reference from the function fadump_calculate_reserve_size() to the > function .init.text:parse_crashkernel() > The function fadump_calculate_reserve_size() references > the function __init parse_crashkernel(). > This is often because fadump_calculate_reserve_size lacks a __init > annotation or the annotation of parse_crashkernel is wrong. > > [...] Applied to powerpc/next. [1/1] powerpc/fadump: Mark fadump_calculate_reserve_size as __init https://git.kernel.org/powerpc/c/fbced1546eaaab57a32e56c974ea8acf10c6abd8 cheers
Re: [PATCH] arch/powerpc/include:fix misspellings in tlbflush.h
On Wed, 3 Mar 2021 19:13:18 -0800, menglong8.d...@gmail.com wrote: > Some typos are found out.The information at the end of the file > does not match the beginning. Applied to powerpc/next. [1/1] arch/powerpc/include:fix misspellings in tlbflush.h https://git.kernel.org/powerpc/c/1a029e0edbc5890f76b64d9899c093212fe6 cheers
Re: [PATCH] powerpc/iommu/debug: fix ifnullfree.cocci warnings
On Fri, 19 Mar 2021 07:44:41 +0800, kernel test robot wrote: > arch/powerpc/kernel/iommu.c:76:2-16: WARNING: NULL check before some freeing > functions is not needed. > > NULL check before some freeing functions is not needed. > > Based on checkpatch warning > "kfree(NULL) is safe this check is probably not required" > and kfreeaddr.cocci by Julia Lawall. > > [...] Applied to powerpc/next. [1/1] powerpc/iommu/debug: fix ifnullfree.cocci warnings https://git.kernel.org/powerpc/c/bbbe563f8490958861777d98871e16960163ea1b cheers
Re: [PATCH] cxl: don't manipulate the mm.mm_users field directly
On Wed, 10 Mar 2021 18:44:05 +0100, Laurent Dufour wrote: > It is better to rely on the API provided by the MM layer instead of > directly manipulating the mm_users field. Applied to powerpc/next. [1/1] cxl: don't manipulate the mm.mm_users field directly https://git.kernel.org/powerpc/c/2d9f69bc5a5a75579b410beb0dc3d313be762c9f cheers
Re: [PATCH v2] powerpc/pseries: export LPAR security flavor in lparcfg
On Fri, 5 Mar 2021 13:55:54 +0100, Laurent Dufour wrote: > This is helpful to read the security flavor from inside the LPAR. > > In /sys/kernel/debug/powerpc/security_features it can be seen if > mitigations are on or off but the level set through the ASMI menu. > Furthermore, reporting it through /proc/powerpc/lparcfg allows an easy > processing by the lparstat command [1]. > > [...] Applied to powerpc/next. [1/1] powerpc/pseries: export LPAR security flavor in lparcfg https://git.kernel.org/powerpc/c/6ce56e1ac380eaa088d3f4c01446e15e195bd541 cheers
Re: [PATCH] powerpc/pci: fix warning comparing pointer to 0
On Mon, 15 Mar 2021 15:35:24 +0800, Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./arch/powerpc/platforms/maple/pci.c:37:16-17: WARNING comparing pointer > to 0. Applied to powerpc/next. [1/1] powerpc/pci: fix warning comparing pointer to 0 https://git.kernel.org/powerpc/c/7a0fdc19f2415683f403abee7bb87085d0c624ad cheers
Re: [RESEND 1/1] powerpc: asm: hvconsole: Move 'hvc_vio_init_early's prototype to shared location
On Wed, 3 Mar 2021 12:46:03 +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for > ‘hvc_vio_init_early’ [-Wmissing-prototypes] > 385 | void __init hvc_vio_init_early(void) > | ^~ Applied to powerpc/next. [1/1] powerpc: asm: hvconsole: Move 'hvc_vio_init_early's prototype to shared location https://git.kernel.org/powerpc/c/13b8219bd00d953cad60431cb47db96eb835c71d cheers
Re: [PATCH] powerpc/chrp: Make hydra_init() static
On Tue, 23 Feb 2021 10:53:45 +0100, Geert Uytterhoeven wrote:
> Commit 407d418f2fd4c20a ("powerpc/chrp: Move PHB discovery") moved the
> sole call to hydra_init() to the source file where it is defined, so it
> can be made static.
Applied to powerpc/next.
[1/1] powerpc/chrp: Make hydra_init() static
https://git.kernel.org/powerpc/c/9634afa67bfd933b231405d05dda37ffa169f32c
cheers
Re: [PATCH] powerpc: remove unneeded semicolon
On Wed, 24 Feb 2021 15:29:21 +0800, Jiapeng Chong wrote: > Fix the following coccicheck warnings: > > ./arch/powerpc/kernel/prom_init.c:2986:2-3: Unneeded semicolon. Applied to powerpc/next. [1/1] powerpc: remove unneeded semicolon https://git.kernel.org/powerpc/c/4f46d57cab3b3410411b395a6fa12a07947cb14a cheers
Re: [PATCH] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings
On Tue, 16 Mar 2021 00:11:48 -0400, He Ying wrote: > warning: symbol 'rfi_flush' was not declared. > warning: symbol 'entry_flush' was not declared. > warning: symbol 'uaccess_flush' was not declared. > We found warnings above in arch/powerpc/kernel/setup_64.c by using > sparse tool. > > Define 'entry_flush' and 'uaccess_flush' as static because they are not > referenced outside the file. Include asm/security_features.h in which > 'rfi_flush' is declared. Applied to powerpc/next. [1/1] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings https://git.kernel.org/powerpc/c/d2313da4ff56bd631a3afe7a17992ed5bd0e04a6 cheers
Re: [PATCH] powerpc/ptrace: Remove duplicate check from pt_regs_check()
On Fri, 5 Mar 2021 14:28:07 +0300, Denis Efremov wrote: > "offsetof(struct pt_regs, msr) == offsetof(struct user_pt_regs, msr)" > checked in pt_regs_check() twice in a row. Remove the second check. Applied to powerpc/next. [1/1] powerpc/ptrace: Remove duplicate check from pt_regs_check() https://git.kernel.org/powerpc/c/0b71b37241784c309bea6bd6a9d2027943c4ab94 cheers
Re: [PATCH] powerpc: powernv: Remove unneeded variable: "rc"
On Fri, 26 Mar 2021 19:53:56 +0800, dingsen...@163.com wrote: > Remove unneeded variable: "rc". Applied to powerpc/next. [1/1] powerpc: powernv: Remove unneeded variable: "rc" https://git.kernel.org/powerpc/c/69931cc387cca289e0415c79ce5389119670066d cheers
Re: [PATCH v3 00/41] powerpc/32: Switch to interrupt entry/exit in C
On Fri, 12 Mar 2021 12:50:09 + (UTC), Christophe Leroy wrote: > This series aims at porting interrupt entry/exit in C on PPC32, using > the work already merged for PPC64. > > First patch is an optimisation around unrecoverable_exception() function. > > Six following patches do minimal changes in 40x in order to be able to enable > MMU > earlier in exception entry. > > [...] Applied to powerpc/next. [01/41] powerpc/traps: Declare unrecoverable_exception() as __noreturn https://git.kernel.org/powerpc/c/a58cbed68315111c663f35603a42547f72acd6f8 [02/41] powerpc/40x: Don't use SPRN_SPRG_SCRATCH0/1 in TLB miss handlers https://git.kernel.org/powerpc/c/52ae92cc290f0506eef9ad5466bb453ce4a9e80e [03/41] powerpc/40x: Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro https://git.kernel.org/powerpc/c/9d3c18a11a930afe65d33527300a42e0872c744d [04/41] powerpc/40x: Save SRR0/SRR1 and r10/r11 earlier in critical exception https://git.kernel.org/powerpc/c/fcd4b43c36c69aa41e79a511edbb06c7020a6061 [05/41] powerpc/40x: Reorder a few instructions in critical exception prolog https://git.kernel.org/powerpc/c/26c468860c32022ffe9caf16691764b77fb8eead [06/41] powerpc/40x: Prepare for enabling MMU in critical exception prolog https://git.kernel.org/powerpc/c/0fc1e93481f67a49f67c9168b71842eeb0998b25 [07/41] powerpc/40x: Prepare normal exception handler for enabling MMU early https://git.kernel.org/powerpc/c/0512aadd750acf72b8906973c34e7092642d4323 [08/41] powerpc/32: Reconcile interrupts in C https://git.kernel.org/powerpc/c/be39e10506830a2e654fb799a48025999f89a6ff [09/41] powerpc/32: Entry cpu time accounting in C https://git.kernel.org/powerpc/c/f93d866e14b746112fb29d69197dd83075bbd28c [10/41] powerpc/32: Handle bookE debugging in C in exception entry https://git.kernel.org/powerpc/c/79f4bb17f18162dd95d6aeb6dc3b7da54d6139aa [11/41] powerpc/32: Use fast instruction to set MSR RI in exception prolog on 8xx https://git.kernel.org/powerpc/c/e464d92b292cc61f8f0791cf87d3646204bbb208 [12/41] powerpc/32: Remove ksp_limit https://git.kernel.org/powerpc/c/5747230645562921b5bc19f6409f7af08fe17c6d [13/41] powerpc/32: Always enable data translation in exception prolog https://git.kernel.org/powerpc/c/7aa8dd67f15731f659390018b5c9fd95f5975b3d [14/41] powerpc/32: Tag DAR in EXCEPTION_PROLOG_2 for the 8xx https://git.kernel.org/powerpc/c/5b1c9a0d7f3bcac591767fa1aad1323564673b26 [15/41] powerpc/32: Enable instruction translation at the same time as data translation https://git.kernel.org/powerpc/c/9b6150fb8942d92e0991b9a4b02fa2e6f6b03238 [16/41] powerpc/32: Statically initialise first emergency context https://git.kernel.org/powerpc/c/a4719f5bb6d7dc220bffdc1b9f5ce5eaa5543581 [17/41] powerpc/32: Add vmap_stack_overflow label inside the macro https://git.kernel.org/powerpc/c/5b5e5bc53def654c2dc437dd327f7a47c48d81d3 [18/41] powerpc/32: Use START_EXCEPTION() as much as possible https://git.kernel.org/powerpc/c/7bf1d7e1abab0d9f47ebce144deadb4409d0d631 [19/41] powerpc/32: Move exception prolog code into .text once MMU is back on https://git.kernel.org/powerpc/c/dc13b889b586f499cc87eb2b0b7e901778b3b5cf [20/41] powerpc/32: Provide a name to exception prolog continuation in virtual mode https://git.kernel.org/powerpc/c/8f844c06f460687b028c675c3fa68f8e735aeb8c [21/41] powerpc/32: Refactor booke critical registers saving https://git.kernel.org/powerpc/c/32d2ca0e969a3620f71dff166a95ebf3f735b72e [22/41] powerpc/32: Perform normal function call in exception entry https://git.kernel.org/powerpc/c/0f2793e33db2e2f062968f2ca789b6826972b05b [23/41] powerpc/32: Always save non volatile registers on exception entry https://git.kernel.org/powerpc/c/e9f99704aafcdbd90ba20b81db2dae8526d8b8e5 [24/41] powerpc/32: Replace ASM exception exit by C exception exit from ppc64 https://git.kernel.org/powerpc/c/b96bae3ae2cb6337c0a1ad160f4cbb0666e5e38b [25/41] powerpc/32: Don't save thread.regs on interrupt entry https://git.kernel.org/powerpc/c/db297c3b07af7856fb7c666fbc9792d8e37556be [26/41] powerpc/32: Set regs parameter in r3 in transfer_to_handler https://git.kernel.org/powerpc/c/e72915560b15f58c2ffe08144d9a7163daa18db4 [27/41] powerpc/32: Call bad_page_fault() from do_page_fault() https://git.kernel.org/powerpc/c/af6f2ce84b2f666762f75f085a7e5d6514743a84 [28/41] powerpc/32: Save trap number on stack in exception prolog https://git.kernel.org/powerpc/c/719e7e212c7e637a795f130dbdd5db6c291e463f [29/41] powerpc/32: Add a prepare_transfer_to_handler macro for exception prologs https://git.kernel.org/powerpc/c/bce4c26a4e324cb096a3768cdc3aad4e2552c3d0 [30/41] powerpc/32: Only restore non volatile registers when required https://git.kernel.org/powerpc/c/8f6ff5bd9b73a7912356f378adfb85e9a4e7ce65 [31/41]
Re: [PATCH 0/3] powerpc/qspinlock: Some tuning updates
On Mon, 8 Mar 2021 17:59:47 -0800, Davidlohr Bueso wrote: > A few updates while going through the powerpc port of the qspinlock. > > Patches 1 and 2 are straightforward, while patch 3 can be considered > more of an rfc as I've only tested on a single machine, and there > could be an alternative way if it doesn't end up being nearly a > universal performance win. > > [...] Applied to powerpc/next. [1/3] powerpc/spinlock: Define smp_mb__after_spinlock only once https://git.kernel.org/powerpc/c/2bf3604c415c9d75311141b8eb6ac8780ef74420 [2/3] powerpc/spinlock: Unserialize spin_is_locked https://git.kernel.org/powerpc/c/66f60522138c2e0d8a3518edd4979df11a2d7525 [3/3] powerpc/qspinlock: Use generic smp_cond_load_relaxed https://git.kernel.org/powerpc/c/deb9b13eb2571fbde164ae012c77985fd14f2f02 cheers
Re: [PATCH] powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS
On Mon, 15 Mar 2021 14:52:51 + (UTC), Christophe Leroy wrote: > In fault.c, #ifdef CONFIG_PPC_MEM_KEYS is not needed because all > functions are always defined, and arch_vma_access_permitted() > always returns true when CONFIG_PPC_MEM_KEYS is not defined so > access_pkey_error() will return false so bad_access_pkey() > will never be called. > > Include linux/pkeys.h to get a definition of vma_pkeys() for > bad_access_pkey(). Applied to powerpc/next. [1/1] powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS https://git.kernel.org/powerpc/c/98c26a72751ecb2ed247cdfd6cb2385f37195707 cheers
Re: [PATCH v2 1/4] powerpc: Enable KFENCE for PPC32
On Thu, 4 Mar 2021 14:35:09 + (UTC), Christophe Leroy wrote: > Add architecture specific implementation details for KFENCE and enable > KFENCE for the ppc32 architecture. In particular, this implements the > required interface in . > > KFENCE requires that attributes for pages from its memory pool can > individually be set. Therefore, force the Read/Write linear map to be > mapped at page granularity. Patch 1 applied to powerpc/next. [1/4] powerpc: Enable KFENCE for PPC32 https://git.kernel.org/powerpc/c/90cbac0e995dd92f7bcf82f74aa50250bf194a4a cheers
Re: [PATCH v1 1/4] powerpc: Activate HAVE_RELIABLE_STACKTRACE for all
On Tue, 16 Mar 2021 07:57:13 + (UTC), Christophe Leroy wrote: > CONFIG_HAVE_RELIABLE_STACKTRACE is applicable to all, no > reason to limit it to book3s/64le Applied to powerpc/next. [1/4] powerpc: Activate HAVE_RELIABLE_STACKTRACE for all https://git.kernel.org/powerpc/c/accdd093f260bc8c8a8f580ee48e49ad5c5f91b2 [2/4] powerpc: Rename 'tsk' parameter into 'task' https://git.kernel.org/powerpc/c/826a307b0a11e605b4be0b2727550b510c4a88cd [3/4] powerpc: Convert stacktrace to generic ARCH_STACKWALK https://git.kernel.org/powerpc/c/a1cdef04f22dd5ad9e1ccf5d05a549c697b7f52d [4/4] powerpc: Fix arch_stack_walk() to have running function as first entry https://git.kernel.org/powerpc/c/a2308836880bf1501ff9373c611dc2970247d42b cheers
Re: [PATCH v1 0/8] Miscellaneous user access improvement
On Wed, 10 Mar 2021 17:56:59 + (UTC), Christophe Leroy wrote:
> Patches 1-3 are cleaning parts of uaccess.h not related
> to put_user/get_user
> Patch 4 removes some usage of consecutives __get_user
> Patches 5 rewrite __patch_instruction to not use uaccess.h internals.
> Patches 6-8 switch some parts of code to user_access_begin/end blocks
>
> All patches are independant.
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/uaccess: Also perform 64 bits copies in unsafe_copy_to_user() on
ppc32
https://git.kernel.org/powerpc/c/c6adc835c68b713360f918d21372c2f34fc228e2
[2/8] powerpc/uaccess: Swap clear_user() and __clear_user()
https://git.kernel.org/powerpc/c/7472199a6eda6a79f9e3b126f52f67f9ce3e1f77
[3/8] powerpc/uaccess: Move copy_mc_xxx() functions down
https://git.kernel.org/powerpc/c/4b8cda58812c1e1bf79d37f2ddff3cf03b7025da
[4/8] powerpc/syscalls: Use sys_old_select() in ppc_select()
https://git.kernel.org/powerpc/c/fd69d544b0e785b11699675154bdfe01a04538cd
[5/8] powerpc/lib: Don't use __put_user_asm_goto() outside of uaccess.h
https://git.kernel.org/powerpc/c/e63ceebdad82f85e48b018abfc6af4ed6958179e
[6/8] powerpc/net: Switch csum_and_copy_{to/from}_user to user_access block
https://git.kernel.org/powerpc/c/164dc6ce368fa23b0aae0e5d12883fff9bf80458
[7/8] powerpc/futex: Switch to user_access block
https://git.kernel.org/powerpc/c/870779f40e99c795ddfafa0dfc43318e51f15127
[8/8] powerpc/ptrace: Convert gpr32_set_common() to user access block
https://git.kernel.org/powerpc/c/93c043e393af7fa218c928d8c62396ba28f1bb84
cheers
Re: [PATCH] powerpc/math: Fix missing __user qualifier for get_user() and other sparse warnings
On Mon, 15 Mar 2021 12:00:09 + (UTC), Christophe Leroy wrote: > Sparse reports the following problems: > > arch/powerpc/math-emu/math.c:228:21: warning: Using plain integer as NULL > pointer > arch/powerpc/math-emu/math.c:228:31: warning: Using plain integer as NULL > pointer > arch/powerpc/math-emu/math.c:228:41: warning: Using plain integer as NULL > pointer > arch/powerpc/math-emu/math.c:228:51: warning: Using plain integer as NULL > pointer > arch/powerpc/math-emu/math.c:237:13: warning: incorrect type in initializer > (different address spaces) > arch/powerpc/math-emu/math.c:237:13:expected unsigned int [noderef] > __user *_gu_addr > arch/powerpc/math-emu/math.c:237:13:got unsigned int [usertype] * > arch/powerpc/math-emu/math.c:226:1: warning: symbol 'do_mathemu' was not > declared. Should it be static? > > [...] Applied to powerpc/next. [1/1] powerpc/math: Fix missing __user qualifier for get_user() and other sparse warnings https://git.kernel.org/powerpc/c/e448e1e774dc0ca307c17e961daf7ede2e635c57 cheers
Re: [PATCH] powerpc/Makefile: Remove workaround for gcc versions below 4.9
On Wed, 10 Mar 2021 12:43:12 + (UTC), Christophe Leroy wrote:
> Commit 6ec4476ac825 ("Raise gcc version requirement to 4.9")
> made it impossible to build with gcc 4.8 and under.
>
> Remove related workaround.
Applied to powerpc/next.
[1/1] powerpc/Makefile: Remove workaround for gcc versions below 4.9
https://git.kernel.org/powerpc/c/802b5560393423166e436c7914b565f3cda9e6b9
cheers
Re: [PATCH] powerpc/embedded6xx: Remove CONFIG_MV64X60
On Thu, 18 Mar 2021 17:25:07 + (UTC), Christophe Leroy wrote:
> Commit 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
> moved the last selector of CONFIG_MV64X60.
>
> As it is not a user selectable config, it can be removed.
Applied to powerpc/next.
[1/1] powerpc/embedded6xx: Remove CONFIG_MV64X60
https://git.kernel.org/powerpc/c/a329ddd472fa2af0c19a73b8658898ae7fd658ad
cheers
Re: [PATCH v2] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
On Mon, 29 Mar 2021 10:27:00 +0800, Chen Huang wrote: > When compiling the powerpc with the SMP disabled, it shows the issue: > > arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’: > arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function > ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? > [-Werror=implicit-function-declaration] > 177 |smp_send_nmi_ipi(c, wd_lockup_ipi, 100); > |^~~~ > |smp_send_stop > cc1: all warnings being treated as errors > make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] > Error 1 > make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2 > make: *** [Makefile:1980: arch/powerpc] Error 2 > make: *** Waiting for unfinished jobs > > [...] Applied to powerpc/next. [1/1] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration https://git.kernel.org/powerpc/c/4fe529449d85e78972fa32761ecc83a0b6db cheers
Re: [PATCH] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
On Sat, 27 Mar 2021 09:49:00 +, Chen Huang wrote: > When compiling the powerpc with the SMP disabled, it shows the issue: > > arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’: > arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function > ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? > [-Werror=implicit-function-declaration] > 177 |smp_send_nmi_ipi(c, wd_lockup_ipi, 100); > |^~~~ > |smp_send_stop > cc1: all warnings being treated as errors > make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] > Error 1 > make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2 > make: *** [Makefile:1980: arch/powerpc] Error 2 > make: *** Waiting for unfinished jobs > > [...] Applied to powerpc/next. [1/1] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration https://git.kernel.org/powerpc/c/4fe529449d85e78972fa32761ecc83a0b6db cheers
Re: [PATCH] powerpc/asm-offsets: GPR14 is not needed either
On Mon, 15 Mar 2021 11:01:26 + (UTC), Christophe Leroy wrote:
> Commit aac6a91fea93 ("powerpc/asm: Remove unused symbols in
> asm-offsets.c") removed GPR15 to GPR31 but kept GPR14,
> probably because it pops up in a couple of comments when doing
> a grep.
>
> However, it was never used either, so remove it as well.
Applied to powerpc/next.
[1/1] powerpc/asm-offsets: GPR14 is not needed either
https://git.kernel.org/powerpc/c/6eeca7a11379e9dd05493bbdba57515b36a2e3cf
cheers
Re: [PATCH v11 0/6] KASAN for powerpc64 radix
Christophe Leroy writes: > Le 23/03/2021 à 02:21, Daniel Axtens a écrit : >> Hi Christophe, >> >>> In the discussion we had long time ago, >>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190806233827.16454-5-...@axtens.net/#2321067 >>> , I challenged you on why it was not possible to implement things the same >>> way as other >>> architectures, in extenso with an early mapping. >>> >>> Your first answer was that too many things were done in real mode at >>> startup. After some discussion >>> you said that finally there was not that much things at startup but the >>> issue was KVM. >>> >>> Now you say that instrumentation on KVM is fully disabled. >>> >>> So my question is, if KVM is not a problem anymore, why not go the standard >>> way with an early shadow >>> ? Then you could also support inline instrumentation. >> >> Fair enough, I've had some trouble both understanding the problem myself >> and clearly articulating it. Let me try again. >> >> We need translations on to access the shadow area. >> >> We reach setup_64.c::early_setup() with translations off. At this point >> we don't know what MMU we're running under, or our CPU features. > > What do you need to know ? Whether it is Hash or Radix, or > more/different details ? Yes, as well as some other details like SLB size, supported segment & page sizes, possibly the CPU version for workarounds, various other device tree things. You also need to know if you're bare metal or in a guest, or on a PS3 ... > IIUC, today we only support KASAN on Radix. Would it make sense to say that a > kernel built with > KASAN can only run on processors having Radix capacility ? Then select > CONFIG_PPC_RADIX_MMU_DEFAULT > when KASAN is set, and accept that the kernel crashes if Radix is not > available ? I would rather not. We already have some options like that (EARLY_DEBUG), and they have caused people to waste time debugging crashes over the years that turned out to just due to the wrong CONFIG selected. >> To determine our MMU and CPU features, early_setup() calls functions >> (dt_cpu_ftrs_init, early_init_devtree) that call out to generic code >> like of_scan_flat_dt. We need to do this before we turn on translations >> because we can't set up the MMU until we know what MMU we have. >> >> So this puts us in a bind: >> >> - We can't set up an early shadow until we have translations on, which >> requires that the MMU is set up. >> >> - We can't set up an MMU until we call out to generic code for FDT >> parsing. >> >> So there will be calls to generic FDT parsing code that happen before the >> early shadow is set up. > > I see some logic in kernel/prom_init.c for detecting MMU. Can we get the > information from there in > order to setup the MMU ? You could find some of the information, but you'd need to stash it somewhere (like the flat device tree :P) because you can't turn the MMU on until we shutdown open firmware. That also doesn't help you on bare metal where we don't use prom_init. >> The setup code also prints a bunch of information about the platform >> with printk() while translations are off, so it wouldn't even be enough >> to disable instrumentation for bits of the generic DT code on ppc64. > > I'm sure the printk() stuff can be avoided or delayed without much problems, > I guess the main > problem is the DT code, isn't it ? We spent many years making printk() work for early boot messages, because it has the nice property of being persisted in dmesg. But possibly we could come up with some workaround for that. Disabling KASAN for the flat DT code seems like it wouldn't be a huge loss, most (all?) of that code should only run at boot anyway. But we also have code spread out in various files that would need to be built without KASAN. See eg. everything called by of_scan_flat_dt(), mmu_early_init_devtree(), pseries_probe_fw_features() pkey_early_init_devtree() etc. Because we can only disable KASAN per-file that would require quite a bit of code movement and related churn. > As far as I can see the code only use udbg_printf() before MMU is on, and > this could be simply > skipped when KASAN is selected, I see no situation where you need early > printk together with KASAN. We definitely use printk() before the MMU is on. >> Does that make sense? If you can figure out how to 'square the circle' >> here I'm all ears. > > Yes it is a lot more clear now, thanks you. Gave a few ideas above, > does it help ? A little? :) It's possible we could do slightly less of the current boot sequence before turning the MMU on. But we would still need to scan the flat device tree, so all that code would be implicated either way. We could also rearrange the early boot code to put bits in separate files so they can be built without KASAN, but like I said above that would be a lot of churn. I don't see a way to fix printk() though, other than not using it during early boot. Maybe that's OK but it feels like a
Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
Arnaldo writes: > On March 25, 2021 11:38:01 AM GMT-03:00, Peter Zijlstra > wrote: >>On Thu, Mar 25, 2021 at 10:01:35AM -0300, Arnaldo Carvalho de Melo >>wrote:. >>> > > Also for CPU_FTR_ARCH_31, capture the two cycle counter >>information in >>> > > two 16 bit fields of perf_sample_weight structure. >>> > >>> > Changes looks fine to me. >>> > >>> > Reviewed-by: Madhavan Srinivasan >>> >>> So who will process the kernel bits? I'm merging the tooling parts, >> >>I was sorta expecting these to go through the powerpc tree. Let me know >>if you want them in tip/perf/core instead. > > Shouldn't matter by which tree it gets upstream, as long as it gets picked :-) I plan to take them, just haven't got around to it yet :} cheers
