[PATCH] arch: powerpc: kernel: fixed some typos
Fixed some typos
Signed-off-by: Ghanshyam Agrawal
---
arch/powerpc/kernel/eeh_pe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index e0ce81279624..8e0c1a8b8641 100644
--- a/arch/powerpc/kernel/eeh_pe.c
+++ b/arch/powerpc/kernel/eeh_pe.c
@@ -24,10 +24,10 @@ static int eeh_pe_aux_size = 0;
static LIST_HEAD(eeh_phb_pe);
/**
- * eeh_set_pe_aux_size - Set PE auxillary data size
- * @size: PE auxillary data size
+ * eeh_set_pe_aux_size - Set PE auxiliary data size
+ * @size: PE auxiliary data size
*
- * Set PE auxillary data size
+ * Set PE auxiliary data size
*/
void eeh_set_pe_aux_size(int size)
{
--
2.25.1
[PATCH] ASoC: fsl_mqs: remove duplicated including
rm the second \#include Signed-off-by: Wang Jinchao --- sound/soc/fsl/fsl_mqs.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/fsl_mqs.c b/sound/soc/fsl/fsl_mqs.c index f2d74ec05cdf..c73e6c141f7e 100644 --- a/sound/soc/fsl/fsl_mqs.c +++ b/sound/soc/fsl/fsl_mqs.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include -- 2.40.0
[powerpc:next] BUILD SUCCESS 8fc63a91e785ef06fb7f1aba59297793d85095f7
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 8fc63a91e785ef06fb7f1aba59297793d85095f7 Merge branch 'smp-topo' into next elapsed time: 1478m configs tested: 170 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc haps_hs_smp_defconfig gcc arc nsimosci_hs_defconfig gcc arc randconfig-001-20231216 gcc arc randconfig-002-20231216 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm axm55xx_defconfig gcc arm defconfig clang armmulti_v5_defconfig clang armmvebu_v7_defconfig gcc armneponset_defconfig clang arm omap1_defconfig clang arm omap2plus_defconfig gcc arm randconfig-001-20231216 gcc arm randconfig-002-20231216 gcc arm randconfig-003-20231216 gcc arm randconfig-004-20231216 gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20231216 gcc arm64 randconfig-002-20231216 gcc arm64 randconfig-003-20231216 gcc arm64 randconfig-004-20231216 gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20231216 gcc csky randconfig-002-20231216 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20231216 clang hexagon randconfig-002-20231216 clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20231215 clang i386 buildonly-randconfig-002-20231215 clang i386 buildonly-randconfig-003-20231215 clang i386 buildonly-randconfig-004-20231215 clang i386 buildonly-randconfig-005-20231215 clang i386 buildonly-randconfig-006-20231215 clang i386defconfig gcc i386 randconfig-001-20231215 clang i386 randconfig-002-20231215 clang i386 randconfig-003-20231215 clang i386 randconfig-004-20231215 clang i386 randconfig-005-20231215 clang i386 randconfig-006-20231215 clang i386 randconfig-011-20231215 gcc i386 randconfig-012-20231215 gcc i386 randconfig-013-20231215 gcc i386 randconfig-014-20231215 gcc i386 randconfig-015-20231215 gcc i386 randconfig-016-20231215 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-001-20231216 gcc loongarch randconfig-002-20231216 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68k apollo_defconfig gcc m68kdefconfig gcc m68kstmark2_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allnoconfig clang mips allyesconfig gcc mips bigsur_defconfig gcc mips gcw0_defconfig gcc mips maltaaprp_defconfig
Re: [PATCH v14 6/6] powerpc: add crash memory hotplug support
On 12/15/23 at 11:29am, Sourabh Jain wrote:
..
> > > +static void update_crash_elfcorehdr(struct kimage *image, struct
> > > memory_notify *mn)
> > > +{
> > > + int ret;
> > > + struct crash_mem *cmem = NULL;
> > > + struct kexec_segment *ksegment;
> > > + void *ptr, *mem, *elfbuf = NULL;
> > > + unsigned long elfsz, memsz, base_addr, size;
> > > +
> > > + ksegment = >segment[image->elfcorehdr_index];
> > > + mem = (void *) ksegment->mem;
> > > + memsz = ksegment->memsz;
> > > +
> > > + ret = get_crash_memory_ranges();
> > > + if (ret) {
> > > + pr_err("Failed to get crash mem range\n");
> > > + return;
> > > + }
> > > +
> > > + /*
> > > + * The hot unplugged memory is part of crash memory ranges,
> > > + * remove it here.
> > > + */
> > > + if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
> > > + base_addr = PFN_PHYS(mn->start_pfn);
> > > + size = mn->nr_pages * PAGE_SIZE;
> > > + ret = remove_mem_range(, base_addr, size);
> > Althouth this is ppc specific, I don't understand. Why don't you
> > recreate the elfcorehdr, but take removing the removed region. Comparing the
> > remove_mem_range() implementation with recreating, I don't see too much
> > benefit from that, and it makes your code more complicated. Just
> > curious, surely ppc people can decide what should be taken.
>
> I am recreating `elfcorehdr` by calling `crash_prepare_elf64_headers()`
> below.
>
> This complexity is necessary to avoid adding hot-removed memory to the
> new `elfcorehdr`.
>
> On powerpc, the memblock list is utilized to prepare the `elfcorehdr`. In
> the
> case of memory hot removal, the memblock list is updated after the arch
> crash hotplug handler is triggered. Thus, the hot-removed memory is
> explicitly
> removed from the crash memory ranges to ensure that the memory ranges
> added to `elfcorehdr` do not include the hot-removed memory.
Ah, I see. Thanks for the explanation. Then please ignore this one.
>
>
> >
> > > + if (ret) {
> > > + pr_err("Failed to remove hot-unplugged from crash
> > > memory ranges.\n");
> > > + return;
> > > + }
> > > + }
> > > +
> > > + ret = crash_prepare_elf64_headers(cmem, false, , );
> > > + if (ret) {
> > > + pr_err("Failed to prepare elf header\n");
> > > + return;
> > > + }
> > > +
> > > + /*
> > > + * It is unlikely that kernel hit this because elfcorehdr kexec
> > > + * segment (memsz) is built with addition space to accommodate growing
> > > + * number of crash memory ranges while loading the kdump kernel. It is
> > > + * Just to avoid any unforeseen case.
> > > + */
> > > + if (elfsz > memsz) {
> > > + pr_err("Updated crash elfcorehdr elfsz %lu > memsz %lu", elfsz,
> > > memsz);
> > > + goto out;
> > > + }
> > > +
> > > + ptr = __va(mem);
> > > + if (ptr) {
> > > + /* Temporarily invalidate the crash image while it is replaced
> > > */
> > > + xchg(_crash_image, NULL);
> > > +
> > > + /* Replace the old elfcorehdr with newly prepared elfcorehdr */
> > > + memcpy((void *)ptr, elfbuf, elfsz);
> > > +
> > > + /* The crash image is now valid once again */
> > > + xchg(_crash_image, image);
> > > + }
> > > +out:
> > > + vfree(elfbuf);
> > > +}
> > > +
> > > /**
> > >* arch_crash_handle_hotplug_event - Handle crash CPU/Memory hotplug
> > > events to update the
> > >* necessary kexec segments based on
> > > the hotplug event.
> > > @@ -572,7 +683,7 @@ int arch_crash_hotplug_cpu_support(struct kimage
> > > *image)
> > >* CPU addition: Update the FDT segment to include the newly added CPU.
> > >* CPU removal: No action is needed, with the assumption that it's okay
> > > to have offline CPUs
> > >* as part of the FDT.
> > > - * Memory addition/removal: No action is taken as this is not yet
> > > supported.
> > > + * Memory addition/removal: Recreate the elfcorehdr segment
> > >*/
> > > void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
> > > {
> > > @@ -593,7 +704,6 @@ void arch_crash_handle_hotplug_event(struct kimage
> > > *image, void *arg)
> > > return;
> > > } else if (hp_action == KEXEC_CRASH_HP_ADD_CPU) {
> > > -
> > > void *fdt, *ptr;
> > > unsigned long mem;
> > > int i, fdt_index = -1;
> > > @@ -628,8 +738,10 @@ void arch_crash_handle_hotplug_event(struct kimage
> > > *image, void *arg)
> > > } else if (hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY ||
> > > hp_action == KEXEC_CRASH_HP_ADD_MEMORY) {
> > > - pr_info_once("Crash update is not supported for memory
> > > hotplug\n");
> > > - return;
> > > + struct memory_notify *mn;
> > > +
> > > + mn = (struct memory_notify *)arg;
> > > + update_crash_elfcorehdr(image, mn);
> > > }
>
Re: [PATCH RFC v4-bis] locking: introduce devm_mutex_init
On 12/15/23 10:58, Andy Shevchenko wrote: On Fri, Dec 15, 2023 at 8:23 AM Christophe Leroy wrote: From: George Stark Using of devm API leads to a certain order of releasing resources. So all dependent resources which are not devm-wrapped should be deleted with respect to devm-release order. Mutex is one of such objects that often is bound to other resources and has no own devm wrapping. Since mutex_destroy() actually does nothing in non-debug builds frequently calling mutex_destroy() is just ignored which is safe for now but wrong formally and can lead to a problem if mutex_destroy() will be extended so introduce devm_mutex_init() Missing period. ... } while (0) #endif /* CONFIG_PREEMPT_RT */ ^^^ (1) +struct device; + +/* + * devm_mutex_init() registers a function that calls mutex_destroy() + * when the ressource is released. + * + * When mutex_destroy() is a not, there is no need to register that + * function. + */ +#ifdef CONFIG_DEBUG_MUTEXES Shouldn't this be #if defined(CONFIG_DEBUG_MUTEXES) && !defined(CONFIG_PREEMPT_RT) (see (1) as well)? CONFIG_DEBUG_MUTEXES and CONFIG_PREEMPT_RT are mutually exclusive. At most one of them can be set. Cheers, Longman
Re: [PATCH RFC v4-bis] locking: introduce devm_mutex_init
Le 15/12/2023 à 16:58, Andy Shevchenko a écrit :
> On Fri, Dec 15, 2023 at 8:23 AM Christophe Leroy
> wrote:
>>
>> From: George Stark
>>
>> Using of devm API leads to a certain order of releasing resources.
>> So all dependent resources which are not devm-wrapped should be deleted
>> with respect to devm-release order. Mutex is one of such objects that
>> often is bound to other resources and has no own devm wrapping.
>> Since mutex_destroy() actually does nothing in non-debug builds
>> frequently calling mutex_destroy() is just ignored which is safe for now
>> but wrong formally and can lead to a problem if mutex_destroy() will be
>> extended so introduce devm_mutex_init()
>
> Missing period.
>
> ...
>
>> } while (0)
>> #endif /* CONFIG_PREEMPT_RT */
>
> ^^^ (1)
>
>> +struct device;
>> +
>> +/*
>> + * devm_mutex_init() registers a function that calls mutex_destroy()
>> + * when the ressource is released.
>> + *
>> + * When mutex_destroy() is a not, there is no need to register that
>> + * function.
>> + */
>> +#ifdef CONFIG_DEBUG_MUTEXES
>
> Shouldn't this be
>
> #if defined(CONFIG_DEBUG_MUTEXES) && !defined(CONFIG_PREEMPT_RT)
>
> (see (1) as well)?
Isn't needed, handled by Kconfig:
config DEBUG_MUTEXES
bool "Mutex debugging: basic checks"
depends on DEBUG_KERNEL && !PREEMPT_RT
>
>> +void mutex_destroy(struct mutex *lock);
>> +int devm_mutex_init(struct device *dev, struct mutex *lock);
>> +#else
>> +static inline void mutex_destroy(struct mutex *lock) {}
>> +
>> +static inline int devm_mutex_init(struct device *dev, struct mutex *lock)
>> +{
>> + mutex_init(lock);
>> + return 0;
>> +}
>> +#endif
>
Re: [PATCH] Reapply "kbuild: Create directory for target DTB"
On Wed, Dec 13, 2023 at 8:22 PM Matthias Schiffer
wrote:
>
> On Tue, 2023-12-12 at 17:13 +, Masahiro Yamada wrote:
> >
> >
> > On Wed, Dec 13, 2023 at 1:17 AM Matthias Schiffer
> > wrote:
> > >
> > > This reverts commit dd7699e37f289fa433f42c6bcc108468c8b198c0.
> > >
> > > On powerpc, dtb-y is usually empty unless CONFIG_OF_ALL_DTBS is set. While
> > > passing a DTB as a make target explicitly works fine, individual DTB
> > > builds may also be pulled in as dependencies by cuImage.% and similar
> > > targets. In this case, nothing creates the arch/powerpc/dts directory,
> > > causing out-of-tree builds to fail.
> > >
> > > Fixes: dd7699e37f28 ("Revert "kbuild: Create directory for target DTB"")
> > > Signed-off-by: Matthias Schiffer
> > > ---
> >
> >
> >
> > NACK.
> >
> > %.dtb is generated by if_changed_dep.
> >
> > Each Makefile is responsible for adding %.dtb to 'targets'
> > if it is pulled in as dependencies of other images.
> >
> > If it does not work for PowerPC, it is a bug in PowerPC Makefile.
> >
> >
> > Just checking arch/powerpc/boot/Makefile,
> > it adds dts/%.dtb and dts/fsl/%.dtb to 'targets'. [1] [2]
> >
> > cuImage.% should be file, but it does not cover all images.
> >
> > Fix arch/powerpc/boot/Makefile.
>
> Ah, thank you for the pointers, I did not quite get the meaning of those
> Makefile lines when first
> reading them. So the issue is that I'm trying to build a cuImage that is not
> added to image-y in the
> powerpc Makefile. It is unfortunate that this leads to a very confusing error
> message about the
> missing dts directory.
>
> I'll send a new patch if I come to the conclusion that I actually need the
> cuImage (for the ancient
> TQM5200 which hasn't really been touched since 2011).
If your target image does not exist in arch/powerpc/boot/Makefile,
one solution might be CONFIG_EXTRA_TARGETS
I see the following code:
image-y += $(CONFIG_EXTRA_TARGETS)
Another solution might be:
image-y += $(filter dtbImage.% uImage.% cuImage.% simpleImage.%
treeImage.%, $(MAKECMDGOALS))
But, I did not test any of them.
> Regards,
> Matthias
>
>
> >
> >
> >
> > [1]
> > https://github.com/torvalds/linux/blob/v6.7-rc5/arch/powerpc/boot/Makefile#L386
> > [2]
> > https://github.com/torvalds/linux/blob/v6.7-rc5/arch/powerpc/boot/Makefile#L388
> >
> >
> >
> > > scripts/Makefile.lib | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > index 1a965fe68e011..3fe0fc46badfe 100644
> > > --- a/scripts/Makefile.lib
> > > +++ b/scripts/Makefile.lib
> > > @@ -389,7 +389,8 @@ $(obj)/%.dtbo.S: $(obj)/%.dtbo FORCE
> > > $(call if_changed,wrap_S_dtb)
> > >
> > > quiet_cmd_dtc = DTC $@
> > > -cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o
> > > $(dtc-tmp) $< ; \
> > > +cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> > > + $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp)
> > > $< ; \
> > > $(DTC) -o $@ -b 0 \
> > > $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
> > > -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> > > --
> > > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > > Amtsgericht München, HRB 105018
> > > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > > https://www.tq-group.com/
> > >
> >
> >
> > --
> > Best Regards
> >
> > Masahiro Yamada
> >
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> https://www.tq-group.com/
--
Best Regards
Masahiro Yamada
Re: [PATCH 01/12] KVM: PPC: Book3S HV nestedv2: Invalidate RPT before deleting a guest
Vaibhav Jain writes:
> Hi Aneesh,
>
> Thanks for looking into this patch. My responses inline below:
>
> "Aneesh Kumar K.V (IBM)" writes:
>
>> Vaibhav Jain writes:
>>
>>> From: Jordan Niethe
>>>
>>> An L0 must invalidate the L2's RPT during H_GUEST_DELETE if this has not
>>> already been done. This is a slow operation that means H_GUEST_DELETE
>>> must return H_BUSY multiple times before completing. Invalidating the
>>> tables before deleting the guest so there is less work for the L0 to do.
>>>
>>> Signed-off-by: Jordan Niethe
>>> ---
>>> arch/powerpc/include/asm/kvm_book3s.h | 1 +
>>> arch/powerpc/kvm/book3s_hv.c | 6 --
>>> arch/powerpc/kvm/book3s_hv_nested.c | 2 +-
>>> 3 files changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_book3s.h
>>> b/arch/powerpc/include/asm/kvm_book3s.h
>>> index 4f527d09c92b..a37736ed3728 100644
>>> --- a/arch/powerpc/include/asm/kvm_book3s.h
>>> +++ b/arch/powerpc/include/asm/kvm_book3s.h
>>> @@ -302,6 +302,7 @@ void kvmhv_nested_exit(void);
>>> void kvmhv_vm_nested_init(struct kvm *kvm);
>>> long kvmhv_set_partition_table(struct kvm_vcpu *vcpu);
>>> long kvmhv_copy_tofrom_guest_nested(struct kvm_vcpu *vcpu);
>>> +void kvmhv_flush_lpid(u64 lpid);
>>> void kvmhv_set_ptbl_entry(u64 lpid, u64 dw0, u64 dw1);
>>> void kvmhv_release_all_nested(struct kvm *kvm);
>>> long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu);
>>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>>> index 1ed6ec140701..5543e8490cd9 100644
>>> --- a/arch/powerpc/kvm/book3s_hv.c
>>> +++ b/arch/powerpc/kvm/book3s_hv.c
>>> @@ -5691,10 +5691,12 @@ static void kvmppc_core_destroy_vm_hv(struct kvm
>>> *kvm)
>>> kvmhv_set_ptbl_entry(kvm->arch.lpid, 0, 0);
>>> }
>>>
>>> - if (kvmhv_is_nestedv2())
>>> + if (kvmhv_is_nestedv2()) {
>>> + kvmhv_flush_lpid(kvm->arch.lpid);
>>> plpar_guest_delete(0, kvm->arch.lpid);
>>>
>>
>> I am not sure I follow the optimization here. I would expect the
>> hypervisor to kill all the translation caches as part of guest_delete.
>> What is the benefit of doing a lpid flush outside the guest delete?
>>
> Thats right. However without this optimization the H_GUEST_DELETE hcall
> in plpar_guest_delete() returns H_BUSY multiple times resulting in
> multiple hcalls to the hypervisor until it finishes. Flushing the guest
> translation cache upfront reduces the number of HCALLs L1 guests has to
> make to delete a L2 guest via H_GUEST_DELETE.
>
can we add that as a comment above that kvmhv_flush_lpid()?
-aneesh
Re: [PATCH RFC v4-bis] locking: introduce devm_mutex_init
On Fri, Dec 15, 2023 at 8:23 AM Christophe Leroy
wrote:
>
> From: George Stark
>
> Using of devm API leads to a certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other resources and has no own devm wrapping.
> Since mutex_destroy() actually does nothing in non-debug builds
> frequently calling mutex_destroy() is just ignored which is safe for now
> but wrong formally and can lead to a problem if mutex_destroy() will be
> extended so introduce devm_mutex_init()
Missing period.
...
> } while (0)
> #endif /* CONFIG_PREEMPT_RT */
^^^ (1)
> +struct device;
> +
> +/*
> + * devm_mutex_init() registers a function that calls mutex_destroy()
> + * when the ressource is released.
> + *
> + * When mutex_destroy() is a not, there is no need to register that
> + * function.
> + */
> +#ifdef CONFIG_DEBUG_MUTEXES
Shouldn't this be
#if defined(CONFIG_DEBUG_MUTEXES) && !defined(CONFIG_PREEMPT_RT)
(see (1) as well)?
> +void mutex_destroy(struct mutex *lock);
> +int devm_mutex_init(struct device *dev, struct mutex *lock);
> +#else
> +static inline void mutex_destroy(struct mutex *lock) {}
> +
> +static inline int devm_mutex_init(struct device *dev, struct mutex *lock)
> +{
> + mutex_init(lock);
> + return 0;
> +}
> +#endif
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] ASoC: fsl_mqs: remove duplicated including
On Fri, 15 Dec 2023 17:13:51 +0800, Wang Jinchao wrote: > rm the second \#include > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_mqs: remove duplicated including commit: e7a4a2fd9a4116286a1523ea1a5cbabd2c36f5b9 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: perf tools arch Arm CMN PMU JSON files build breakage on ubuntu 18.04 cross build
Em Fri, Dec 15, 2023 at 11:41:19AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Dec 15, 2023 at 11:39:14AM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Mon, Mar 27, 2023 at 09:52:11AM +0530, kajoljain escreveu: > > > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position > > > > 55090: ordinal not in range(128) > > > > CC /tmp/build/perf/tests/expr.o > > > > pmu-events/Build:35: recipe for target > > > > '/tmp/build/perf/pmu-events/pmu-events.c' failed > > > > make[3]: *** [/tmp/build/perf/pmu-events/pmu-events.c] Error 1 > > > > make[3]: *** Deleting file '/tmp/build/perf/pmu-events/pmu-events.c' > > > > Makefile.perf:679: recipe for target > > > > '/tmp/build/perf/pmu-events/pmu-events-in.o' failed > > > > make[2]: *** [/tmp/build/perf/pmu-events/pmu-events-in.o] Error 2 > > > > make[2]: *** Waiting for unfinished jobs > > > > > > Now jevents is an opt-out feature so I'm noticing these problems. > > > > > Thanks for raising it. I will check this issue. > > > > Now I'm seeing this on: > > Jing, > > Please take a look at: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9df8731c0941f3add30f96745a62586a0c9d52 > > For the fix for the ppc case above. Its the only .json file with that issue: ⬢[acme@toolbox perf-tools-next]$ find tools/perf/pmu-events/ -name "*.json" | xargs file -i | grep -v us-ascii tools/perf/pmu-events/arch/arm64/arm/cmn/sys/cmn.json: application/json; charset=utf-8 ⬢[acme@toolbox perf-tools-next]$ - Arnaldo
Re: perf tools arch Arm CMN PMU JSON files build breakage on ubuntu 18.04 cross build
Em Fri, Dec 15, 2023 at 11:39:14AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Mar 27, 2023 at 09:52:11AM +0530, kajoljain escreveu: > > On 3/23/23 18:41, Arnaldo Carvalho de Melo wrote: > > > Exception processing pmu-events/arch/powerpc/power9/other.json > > > Traceback (most recent call last): > > > File "pmu-events/jevents.py", line 997, in > > > main() > > > File "pmu-events/jevents.py", line 979, in main > > > ftw(arch_path, [], preprocess_one_file) > > > File "pmu-events/jevents.py", line 935, in ftw > > > ftw(item.path, parents + [item.name], action) > > > File "pmu-events/jevents.py", line 933, in ftw > > > action(parents, item) > > > File "pmu-events/jevents.py", line 514, in preprocess_one_file > > > for event in read_json_events(item.path, topic): > > > File "pmu-events/jevents.py", line 388, in read_json_events > > > events = json.load(open(path), object_hook=JsonEvent) > > > File "/usr/lib/python3.6/json/__init__.py", line 296, in load > > > return loads(fp.read(), > > > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > > > return codecs.ascii_decode(input, self.errors)[0] > > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position > > > 55090: ordinal not in range(128) > > > CC /tmp/build/perf/tests/expr.o > > > pmu-events/Build:35: recipe for target > > > '/tmp/build/perf/pmu-events/pmu-events.c' failed > > > make[3]: *** [/tmp/build/perf/pmu-events/pmu-events.c] Error 1 > > > make[3]: *** Deleting file '/tmp/build/perf/pmu-events/pmu-events.c' > > > Makefile.perf:679: recipe for target > > > '/tmp/build/perf/pmu-events/pmu-events-in.o' failed > > > make[2]: *** [/tmp/build/perf/pmu-events/pmu-events-in.o] Error 2 > > > make[2]: *** Waiting for unfinished jobs > > > > Now jevents is an opt-out feature so I'm noticing these problems. > > > Thanks for raising it. I will check this issue. > > Now I'm seeing this on: Jing, Please take a look at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9df8731c0941f3add30f96745a62586a0c9d52 For the fix for the ppc case above. - Arnaldo > Exception processing pmu-events/arch/arm64/arm/cmn/sys/cmn.json > Traceback (most recent call last): > File "pmu-events/jevents.py", line 1285, in > main() > File "pmu-events/jevents.py", line 1267, in main > ftw(arch_path, [], preprocess_one_file) > File "pmu-events/jevents.py", line 1217, in ftw > ftw(item.path, parents + [item.name], action) > File "pmu-events/jevents.py", line 1217, in ftw > ftw(item.path, parents + [item.name], action) > File "pmu-events/jevents.py", line 1217, in ftw > ftw(item.path, parents + [item.name], action) > File "pmu-events/jevents.py", line 1215, in ftw > action(parents, item) > File "pmu-events/jevents.py", line 599, in preprocess_one_file > for event in read_json_events(item.path, topic): > File "pmu-events/jevents.py", line 416, in read_json_events > events = json.load(open(path), object_hook=JsonEvent) > File "/usr/lib/python3.6/json/__init__.py", line 296, in load > return loads(fp.read(), > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3071: > ordinal not in range(128) > -- - Arnaldo
perf tools arch Arm CMN PMU JSON files build breakage on ubuntu 18.04 cross build
Em Mon, Mar 27, 2023 at 09:52:11AM +0530, kajoljain escreveu: > On 3/23/23 18:41, Arnaldo Carvalho de Melo wrote: > > Exception processing pmu-events/arch/powerpc/power9/other.json > > Traceback (most recent call last): > > File "pmu-events/jevents.py", line 997, in > > main() > > File "pmu-events/jevents.py", line 979, in main > > ftw(arch_path, [], preprocess_one_file) > > File "pmu-events/jevents.py", line 935, in ftw > > ftw(item.path, parents + [item.name], action) > > File "pmu-events/jevents.py", line 933, in ftw > > action(parents, item) > > File "pmu-events/jevents.py", line 514, in preprocess_one_file > > for event in read_json_events(item.path, topic): > > File "pmu-events/jevents.py", line 388, in read_json_events > > events = json.load(open(path), object_hook=JsonEvent) > > File "/usr/lib/python3.6/json/__init__.py", line 296, in load > > return loads(fp.read(), > > File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode > > return codecs.ascii_decode(input, self.errors)[0] > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 55090: > > ordinal not in range(128) > > CC /tmp/build/perf/tests/expr.o > > pmu-events/Build:35: recipe for target > > '/tmp/build/perf/pmu-events/pmu-events.c' failed > > make[3]: *** [/tmp/build/perf/pmu-events/pmu-events.c] Error 1 > > make[3]: *** Deleting file '/tmp/build/perf/pmu-events/pmu-events.c' > > Makefile.perf:679: recipe for target > > '/tmp/build/perf/pmu-events/pmu-events-in.o' failed > > make[2]: *** [/tmp/build/perf/pmu-events/pmu-events-in.o] Error 2 > > make[2]: *** Waiting for unfinished jobs > > Now jevents is an opt-out feature so I'm noticing these problems. > Thanks for raising it. I will check this issue. Now I'm seeing this on: Exception processing pmu-events/arch/arm64/arm/cmn/sys/cmn.json Traceback (most recent call last): File "pmu-events/jevents.py", line 1285, in main() File "pmu-events/jevents.py", line 1267, in main ftw(arch_path, [], preprocess_one_file) File "pmu-events/jevents.py", line 1217, in ftw ftw(item.path, parents + [item.name], action) File "pmu-events/jevents.py", line 1217, in ftw ftw(item.path, parents + [item.name], action) File "pmu-events/jevents.py", line 1217, in ftw ftw(item.path, parents + [item.name], action) File "pmu-events/jevents.py", line 1215, in ftw action(parents, item) File "pmu-events/jevents.py", line 599, in preprocess_one_file for event in read_json_events(item.path, topic): File "pmu-events/jevents.py", line 416, in read_json_events events = json.load(open(path), object_hook=JsonEvent) File "/usr/lib/python3.6/json/__init__.py", line 296, in load return loads(fp.read(), File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3071: ordinal not in range(128)
[PATCH] powerpc/64s: Increase default stack size to 32KB
There are reports of kernels crashing due to stack overflow while running OpenShift (Kubernetes). The primary contributor to the stack usage seems to be openvswitch, which is used by OVN-Kubernetes (based on OVN (Open Virtual Network)), but NFS also contributes in some stack traces. There may be some opportunities to reduce stack usage in the openvswitch code, but doing so potentially require tradeoffs vs performance, and also requires testing across architectures. Looking at stack usage across the kernel (using -fstack-usage), shows that ppc64le stack frames are on average 50-100% larger than the equivalent function built for x86-64. Which is not surprising given the minimum stack frame size is 32 bytes on ppc64le vs 16 bytes on x86-64. So increase the default stack size to 32KB for the modern 64-bit Book3S platforms, ie. pseries (virtualised) and powernv (bare metal). That leaves the older systems like G5s, and the AmigaOne (pasemi) with a 16KB stack which should be sufficient on those machines. Signed-off-by: Michael Ellerman --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 6f105ee4f3cf..2df545c1446e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -858,6 +858,7 @@ config THREAD_SHIFT int "Thread shift" if EXPERT range 13 15 default "15" if PPC_256K_PAGES + default "15" if PPC_PSERIES || PPC_POWERNV default "14" if PPC64 default "13" help -- 2.43.0
[powerpc:fixes-test] BUILD SUCCESS d2441d3e8c0c076d0a2e705fa235c76869a85140
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: d2441d3e8c0c076d0a2e705fa235c76869a85140 MAINTAINERS: powerpc: Add Aneesh & Naveen elapsed time: 1499m configs tested: 79 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alpha defconfig gcc arc allnoconfig gcc arc defconfig gcc arc randconfig-001-20231215 gcc arc randconfig-002-20231215 gcc arm allnoconfig gcc arm defconfig clang arm randconfig-001-20231215 clang arm randconfig-002-20231215 clang arm64 allnoconfig gcc arm64 defconfig gcc csky allnoconfig gcc cskydefconfig gcc hexagon allnoconfig clang hexagon defconfig clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20231215 clang i386 buildonly-randconfig-002-20231215 clang i386 buildonly-randconfig-003-20231215 clang i386 buildonly-randconfig-004-20231215 clang i386 buildonly-randconfig-005-20231215 clang i386 buildonly-randconfig-006-20231215 clang i386defconfig gcc i386 randconfig-001-20231215 clang i386 randconfig-002-20231215 clang i386 randconfig-003-20231215 clang i386 randconfig-004-20231215 clang i386 randconfig-005-20231215 clang i386 randconfig-006-20231215 clang i386 randconfig-011-20231215 gcc i386 randconfig-012-20231215 gcc i386 randconfig-013-20231215 gcc i386 randconfig-014-20231215 gcc i386 randconfig-015-20231215 gcc i386 randconfig-016-20231215 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allnoconfig clang mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc sh allmodconfig gcc sh allyesconfig gcc sparcallmodconfig gcc sparc64 allmodconfig gcc sparc64 allyesconfig gcc um allmodconfig clang um allyesconfig clang x86_64allnoconfig gcc x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20231215 clang x86_64 buildonly-randconfig-002-20231215 clang x86_64 buildonly-randconfig-003-20231215 clang x86_64 buildonly-randconfig-004-20231215 clang x86_64 buildonly-randconfig-005-20231215 clang x86_64 defconfig gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH] arch: powerpc: kernel: fixed some typos
Le 15/12/2023 à 12:58, Ghanshyam Agrawal a écrit :
> [Vous ne recevez pas souvent de courriers de ghanshyam1...@gmail.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Fixed some typos
This kind of change is a waist of time for us and a waist of time for you.
Please fix those type when you do real changes to the file, otherwise
the changes are pointless, everyone is able to understand the comments
even with the typo.
Christophe
>
> Signed-off-by: Ghanshyam Agrawal
> ---
> arch/powerpc/kernel/eeh_pe.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
> index e0ce81279624..8e0c1a8b8641 100644
> --- a/arch/powerpc/kernel/eeh_pe.c
> +++ b/arch/powerpc/kernel/eeh_pe.c
> @@ -24,10 +24,10 @@ static int eeh_pe_aux_size = 0;
> static LIST_HEAD(eeh_phb_pe);
>
> /**
> - * eeh_set_pe_aux_size - Set PE auxillary data size
> - * @size: PE auxillary data size
> + * eeh_set_pe_aux_size - Set PE auxiliary data size
> + * @size: PE auxiliary data size
>*
> - * Set PE auxillary data size
> + * Set PE auxiliary data size
>*/
> void eeh_set_pe_aux_size(int size)
> {
> --
> 2.25.1
>
[PATCH][next] powerpc/selftests: Fix spelling mistake "EACCESS" -> "EACCES"
There is a spelling mistake of the EACCES error name, fix it.
Signed-off-by: Colin Ian King
---
tools/testing/selftests/powerpc/papr_sysparm/papr_sysparm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/papr_sysparm/papr_sysparm.c
b/tools/testing/selftests/powerpc/papr_sysparm/papr_sysparm.c
index d5436de5b8ed..f56c15a11e2f 100644
--- a/tools/testing/selftests/powerpc/papr_sysparm/papr_sysparm.c
+++ b/tools/testing/selftests/powerpc/papr_sysparm/papr_sysparm.c
@@ -177,7 +177,7 @@ static const struct sysparm_test sysparm_tests[] = {
},
{
.function = set_with_ro_fd,
- .description = "PAPR_IOC_SYSPARM_SET returns EACCESS on
read-only fd",
+ .description = "PAPR_IOC_SYSPARM_SET returns EACCES on
read-only fd",
},
};
--
2.39.2
[PATCH v5 6/6] docs: trusted-encrypted: add DCP as new trust source
Update the documentation for trusted and encrypted KEYS with DCP as new trust source: - Describe security properties of DCP trust source - Describe key usage - Document blob format Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir --- .../security/keys/trusted-encrypted.rst | 85 +++ 1 file changed, 85 insertions(+) diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 9bc9db8ec651..4452070afbe9 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -42,6 +42,14 @@ safe. randomly generated and fused into each SoC at manufacturing time. Otherwise, a common fixed test key is used instead. + (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + Rooted to a one-time programmable key (OTP) that is generally burnt + in the on-chip fuses and is accessible to the DCP encryption engine only. + DCP provides two keys that can be used as root of trust: the OTP key + and the UNIQUE key. Default is to use the UNIQUE key, but selecting + the OTP key can be done via a module parameter (dcp_use_otp_key). + * Execution isolation (1) TPM @@ -57,6 +65,12 @@ safe. Fixed set of operations running in isolated execution environment. + (4) DCP + + Fixed set of cryptographic operations running in isolated execution + environment. Only basic blob key encryption is executed there. + The actual key sealing/unsealing is done on main processor/kernel space. + * Optional binding to platform integrity state (1) TPM @@ -79,6 +93,11 @@ safe. Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs for platform integrity. + (4) DCP + + Relies on Secure/Trusted boot process (called HAB by vendor) for + platform integrity. + * Interfaces and APIs (1) TPM @@ -94,6 +113,11 @@ safe. Interface is specific to silicon vendor. + (4) DCP + + Vendor-specific API that is implemented as part of the DCP crypto driver in + ``drivers/crypto/mxs-dcp.c``. + * Threat model The strength and appropriateness of a particular trust source for a given @@ -129,6 +153,13 @@ selected trust source: CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device is probed. + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + The DCP hardware device itself does not provide a dedicated RNG interface, + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have + a dedicated hardware RNG that is independent from DCP which can be enabled + to back the kernel RNG. + Users may override this by specifying ``trusted.rng=kernel`` on the kernel command-line to override the used RNG with the kernel's random number pool. @@ -231,6 +262,19 @@ Usage:: CAAM-specific format. The key length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). +Trusted Keys usage: DCP +--- + +Usage:: + +keyctl add trusted name "new keylen" ring +keyctl add trusted name "load hex_blob" ring +keyctl print keyid + +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format +specific to this DCP key-blob implementation. The key length for new keys is +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). + Encrypted Keys usage @@ -426,3 +470,44 @@ string length. privkey is the binary representation of TPM2B_PUBLIC excluding the initial TPM2B header which can be reconstructed from the ASN.1 octed string length. + +DCP Blob Format +--- + +The Data Co-Processor (DCP) provides hardware-bound AES keys using its +AES encryption engine only. It does not provide direct key sealing/unsealing. +To make DCP hardware encryption keys usable as trust source, we define +our own custom format that uses a hardware-bound key to secure the sealing +key stored in the key blob. + +Whenever a new trusted key using DCP is generated, we generate a random 128-bit +blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to +encrypt the trusted key payload using AES-128-GCM. + +The BEK itself is encrypted using the hardware-bound key using the DCP's AES +encryption engine with AES-128-ECB. The encrypted BEK, generated nonce, +BEK-encrypted payload and authentication tag make up the blob format together +with a version number, payload length and authentication tag:: + +/* + * struct dcp_blob_fmt - DCP BLOB format. + * + * @fmt_version: Format version, currently being %1 + * @blob_key: Random AES 128 key which is used to encrypt @payload, + *
[PATCH v5 5/6] docs: document DCP-backed trusted keys kernel params
Document the kernel parameters trusted.dcp_use_otp_key and trusted.dcp_skip_zk_test for DCP-backed trusted keys. Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir --- Documentation/admin-guide/kernel-parameters.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 0a1731a0f0ef..c11eda8b38e0 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6566,6 +6566,7 @@ - "tpm" - "tee" - "caam" + - "dcp" If not specified then it defaults to iterating through the trust source list starting with TPM and assigns the first trust source as a backend which is initialized @@ -6581,6 +6582,18 @@ If not specified, "default" is used. In this case, the RNG's choice is left to each individual trust source. + trusted.dcp_use_otp_key + This is intended to be used in combination with + trusted.source=dcp and will select the DCP OTP key + instead of the DCP UNIQUE key blob encryption. + + trusted.dcp_skip_zk_test + This is intended to be used in combination with + trusted.source=dcp and will disable the check if all + the blob key is zero'ed. This is helpful for situations where + having this key zero'ed is acceptable. E.g. in testing + scenarios. + tsc=Disable clocksource stability checks for TSC. Format: [x86] reliable: mark tsc clocksource as reliable, this -- 2.35.3
[PATCH v5 4/6] MAINTAINERS: add entry for DCP-based trusted keys
This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip found in smaller i.MX SoCs. Signed-off-by: David Gstir --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 90f13281d297..988d01226131 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11647,6 +11647,15 @@ S: Maintained F: include/keys/trusted_caam.h F: security/keys/trusted-keys/trusted_caam.c +KEYS-TRUSTED-DCP +M: David Gstir +R: sigma star Kernel Team +L: linux-integr...@vger.kernel.org +L: keyri...@vger.kernel.org +S: Supported +F: include/keys/trusted_dcp.h +F: security/keys/trusted-keys/trusted_dcp.c + KEYS-TRUSTED-TEE M: Sumit Garg L: linux-integr...@vger.kernel.org -- 2.35.3
[PATCH v5 3/6] KEYS: trusted: Introduce NXP DCP-backed trusted keys
DCP (Data Co-Processor) is the little brother of NXP's CAAM IP.
Beside of accelerated crypto operations, it also offers support for
hardware-bound keys. Using this feature it is possible to implement a blob
mechanism similar to what CAAM offers. Unlike on CAAM, constructing and
parsing the blob has to happen in software (i.e. the kernel).
The software-based blob format used by DCP trusted keys encrypts
the payload using AES-128-GCM with a freshly generated random key and nonce.
The random key itself is AES-128-ECB encrypted using the DCP unique
or OTP key.
The DCP trusted key blob format is:
/*
* struct dcp_blob_fmt - DCP BLOB format.
*
* @fmt_version: Format version, currently being %1
* @blob_key: Random AES 128 key which is used to encrypt @payload,
*@blob_key itself is encrypted with OTP or UNIQUE device key in
*AES-128-ECB mode by DCP.
* @nonce: Random nonce used for @payload encryption.
* @payload_len: Length of the plain text @payload.
* @payload: The payload itself, encrypted using AES-128-GCM and @blob_key,
* GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it.
*
* The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len +
* AES_BLOCK_SIZE.
*/
struct dcp_blob_fmt {
__u8 fmt_version;
__u8 blob_key[AES_KEYSIZE_128];
__u8 nonce[AES_KEYSIZE_128];
__le32 payload_len;
__u8 payload[];
} __packed;
By default the unique key is used. It is also possible to use the
OTP key. While the unique key should be unique it is not documented how
this key is derived. Therefore selection the OTP key is supported as
well via the use_otp_key module parameter.
Co-developed-by: Richard Weinberger
Signed-off-by: Richard Weinberger
Co-developed-by: David Oberhollenzer
Signed-off-by: David Oberhollenzer
Signed-off-by: David Gstir
---
include/keys/trusted_dcp.h| 11 +
security/keys/trusted-keys/Kconfig| 8 +
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_core.c | 6 +-
security/keys/trusted-keys/trusted_dcp.c | 311 ++
5 files changed, 337 insertions(+), 1 deletion(-)
create mode 100644 include/keys/trusted_dcp.h
create mode 100644 security/keys/trusted-keys/trusted_dcp.c
diff --git a/include/keys/trusted_dcp.h b/include/keys/trusted_dcp.h
new file mode 100644
index ..9aaa42075b40
--- /dev/null
+++ b/include/keys/trusted_dcp.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2021 sigma star gmbh
+ */
+
+#ifndef TRUSTED_DCP_H
+#define TRUSTED_DCP_H
+
+extern struct trusted_key_ops dcp_trusted_key_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig
b/security/keys/trusted-keys/Kconfig
index 553dc117f385..1fb8aa001995 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -39,6 +39,14 @@ config TRUSTED_KEYS_CAAM
Enable use of NXP's Cryptographic Accelerator and Assurance Module
(CAAM) as trusted key backend.
+config TRUSTED_KEYS_DCP
+ bool "DCP-based trusted keys"
+ depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
+ default y
+ select HAVE_TRUSTED_KEYS
+ help
+ Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
+
if !HAVE_TRUSTED_KEYS
comment "No trust source selected!"
endif
diff --git a/security/keys/trusted-keys/Makefile
b/security/keys/trusted-keys/Makefile
index 735aa0bc08ef..f0f3b27f688b 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -14,3 +14,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
+
+trusted-$(CONFIG_TRUSTED_KEYS_DCP) += trusted_dcp.o
diff --git a/security/keys/trusted-keys/trusted_core.c
b/security/keys/trusted-keys/trusted_core.c
index c6fc50d67214..8af0988be850 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -30,7 +31,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
static char *trusted_key_source;
module_param_named(source, trusted_key_source, charp, 0);
-MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)");
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam or dcp)");
static const struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TRUSTED_KEYS_TPM)
@@ -42,6 +43,9 @@ static const struct trusted_key_source trusted_key_sources[]
= {
#if defined(CONFIG_TRUSTED_KEYS_CAAM)
{ "caam", _key_caam_ops },
#endif
+#if defined(CONFIG_TRUSTED_KEYS_DCP)
+ { "dcp", _trusted_key_ops },
+#endif
};
DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
diff --git a/security/keys/trusted-keys/trusted_dcp.c
[PATCH v5 2/6] KEYS: trusted: improve scalability of trust source config
Checking if at least one valid trust source is selected does not scale and becomes hard to read. This improves this in preparation for the DCP trust source. Signed-off-by: David Gstir --- security/keys/trusted-keys/Kconfig | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig index dbfdd8536468..553dc117f385 100644 --- a/security/keys/trusted-keys/Kconfig +++ b/security/keys/trusted-keys/Kconfig @@ -1,3 +1,6 @@ +config HAVE_TRUSTED_KEYS + bool + config TRUSTED_KEYS_TPM bool "TPM-based trusted keys" depends on TCG_TPM >= TRUSTED_KEYS @@ -9,6 +12,7 @@ config TRUSTED_KEYS_TPM select ASN1_ENCODER select OID_REGISTRY select ASN1 + select HAVE_TRUSTED_KEYS help Enable use of the Trusted Platform Module (TPM) as trusted key backend. Trusted keys are random number symmetric keys, @@ -20,6 +24,7 @@ config TRUSTED_KEYS_TEE bool "TEE-based trusted keys" depends on TEE >= TRUSTED_KEYS default y + select HAVE_TRUSTED_KEYS help Enable use of the Trusted Execution Environment (TEE) as trusted key backend. @@ -29,10 +34,11 @@ config TRUSTED_KEYS_CAAM depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS select CRYPTO_DEV_FSL_CAAM_BLOB_GEN default y + select HAVE_TRUSTED_KEYS help Enable use of NXP's Cryptographic Accelerator and Assurance Module (CAAM) as trusted key backend. -if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE && !TRUSTED_KEYS_CAAM -comment "No trust source selected!" +if !HAVE_TRUSTED_KEYS + comment "No trust source selected!" endif -- 2.35.3
[PATCH v5 1/6] crypto: mxs-dcp: Add support for hardware-bound keys
DCP is capable of performing AES with two hardware-bound keys:
- The one-time programmable (OTP) key which is burnt via on-chip fuses
- The unique key (UK) which is derived from the OTP key
In addition to the two hardware-bound keys, DCP also supports
storing keys in 4 dedicated key slots within its secure memory area
(internal SRAM).
These keys are not stored in main memory and are therefore
not directly accessible by the operating system. To use them
for AES operations, a one-byte key reference has to supplied
with the DCP operation descriptor in the control register.
This adds support for using any of these 6 keys through the crypto API
via their key reference after they have been set up. The main purpose
is to add support for DCP-backed trusted keys. Other use cases are
possible too (see similar existing paes implementations), but these
should carefully be evaluated as e.g. enabling AF_ALG will give
userspace full access to use keys. In scenarios with untrustworthy
userspace, this will enable en-/decryption oracles.
Co-developed-by: Richard Weinberger
Signed-off-by: Richard Weinberger
Co-developed-by: David Oberhollenzer
Signed-off-by: David Oberhollenzer
Signed-off-by: David Gstir
Acked-by: Herbert Xu
---
drivers/crypto/mxs-dcp.c | 104 ++-
include/soc/fsl/dcp.h| 17 +++
2 files changed, 110 insertions(+), 11 deletions(-)
create mode 100644 include/soc/fsl/dcp.h
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index f6b7bce0e656..2dc664fb2faf 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -101,6 +102,7 @@ struct dcp_async_ctx {
struct crypto_skcipher *fallback;
unsigned intkey_len;
uint8_t key[AES_KEYSIZE_128];
+ boolkey_referenced;
};
struct dcp_aes_req_ctx {
@@ -155,6 +157,7 @@ static struct dcp *global_sdcp;
#define MXS_DCP_CONTROL0_HASH_TERM (1 << 13)
#define MXS_DCP_CONTROL0_HASH_INIT (1 << 12)
#define MXS_DCP_CONTROL0_PAYLOAD_KEY (1 << 11)
+#define MXS_DCP_CONTROL0_OTP_KEY (1 << 10)
#define MXS_DCP_CONTROL0_CIPHER_ENCRYPT(1 << 8)
#define MXS_DCP_CONTROL0_CIPHER_INIT (1 << 9)
#define MXS_DCP_CONTROL0_ENABLE_HASH (1 << 6)
@@ -168,6 +171,8 @@ static struct dcp *global_sdcp;
#define MXS_DCP_CONTROL1_CIPHER_MODE_ECB (0 << 4)
#define MXS_DCP_CONTROL1_CIPHER_SELECT_AES128 (0 << 0)
+#define MXS_DCP_CONTROL1_KEY_SELECT_SHIFT 8
+
static int mxs_dcp_start_dma(struct dcp_async_ctx *actx)
{
int dma_err;
@@ -224,13 +229,16 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
struct dcp *sdcp = global_sdcp;
struct dcp_dma_desc *desc = >coh->desc[actx->chan];
struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req);
+ bool key_referenced = actx->key_referenced;
int ret;
- key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
- 2 * AES_KEYSIZE_128, DMA_TO_DEVICE);
- ret = dma_mapping_error(sdcp->dev, key_phys);
- if (ret)
- return ret;
+ if (!key_referenced) {
+ key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
+ 2 * AES_KEYSIZE_128, DMA_TO_DEVICE);
+ ret = dma_mapping_error(sdcp->dev, key_phys);
+ if (ret)
+ return ret;
+ }
src_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_in_buf,
DCP_BUF_SZ, DMA_TO_DEVICE);
@@ -255,8 +263,12 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
MXS_DCP_CONTROL0_INTERRUPT |
MXS_DCP_CONTROL0_ENABLE_CIPHER;
- /* Payload contains the key. */
- desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
+ if (key_referenced)
+ /* Set OTP key bit to select the key via KEY_SELECT. */
+ desc->control0 |= MXS_DCP_CONTROL0_OTP_KEY;
+ else
+ /* Payload contains the key. */
+ desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
if (rctx->enc)
desc->control0 |= MXS_DCP_CONTROL0_CIPHER_ENCRYPT;
@@ -270,6 +282,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
else
desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_CBC;
+ if (key_referenced)
+ desc->control1 |= sdcp->coh->aes_key[0] <<
MXS_DCP_CONTROL1_KEY_SELECT_SHIFT;
+
desc->next_cmd_addr = 0;
desc->source = src_phys;
desc->destination = dst_phys;
@@ -284,9 +299,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
err_dst:
dma_unmap_single(sdcp->dev, src_phys, DCP_BUF_SZ, DMA_TO_DEVICE);
err_src:
-
[PATCH v5 0/6] DCP as trusted keys backend
This is a revival of the previous patch set submitted by Richard Weinberger:
https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/
v4 is here:
https://lore.kernel.org/keyrings/20231024162024.51260-1-da...@sigma-star.at/
v4 -> v5:
- Make Kconfig for trust source check scalable as suggested by Jarkko Sakkinen
- Add Acked-By from Herbert Xu to patch #1 - thanks!
v3 -> v4:
- Split changes on MAINTAINERS and documentation into dedicated patches
- Use more concise wording in commit messages as suggested by Jarkko Sakkinen
v2 -> v3:
- Addressed review comments from Jarkko Sakkinen
v1 -> v2:
- Revive and rebase to latest version
- Include review comments from Ahmad Fatoum
The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such
as i.mx6ull.
Similar to the CAAM engine used in more powerful SoCs, DCP can AES-
encrypt/decrypt user data using a unique, never-disclosed,
device-specific key. Unlike CAAM though, it cannot directly wrap and
unwrap blobs in hardware. As DCP offers only the bare minimum feature
set and a blob mechanism needs aid from software. A blob in this case
is a piece of sensitive data (e.g. a key) that is encrypted and
authenticated using the device-specific key so that unwrapping can only
be done on the hardware where the blob was wrapped.
This patch series adds a DCP based, trusted-key backend and is similar
in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM.
It is of interest for similar use cases as the CAAM patch set, but for
lower end devices, where CAAM is not available.
Because constructing and parsing the blob has to happen in software,
we needed to decide on a blob format and chose the following:
struct dcp_blob_fmt {
__u8 fmt_version;
__u8 blob_key[AES_KEYSIZE_128];
__u8 nonce[AES_KEYSIZE_128];
__le32 payload_len;
__u8 payload[];
} __packed;
The `fmt_version` is currently 1.
The encrypted key is stored in the payload area. It is AES-128-GCM
encrypted using `blob_key` and `nonce`, GCM auth tag is attached at
the end of the payload (`payload_len` does not include the size of
the auth tag).
The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using
the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated
randomly, when sealing/exporting the DCP blob.
This patchset was tested with dm-crypt on an i.MX6ULL board.
[0]
https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fat...@pengutronix.de/
David Gstir (6):
crypto: mxs-dcp: Add support for hardware-bound keys
KEYS: trusted: improve scalability of trust source config
KEYS: trusted: Introduce NXP DCP-backed trusted keys
MAINTAINERS: add entry for DCP-based trusted keys
docs: document DCP-backed trusted keys kernel params
docs: trusted-encrypted: add DCP as new trust source
.../admin-guide/kernel-parameters.txt | 13 +
.../security/keys/trusted-encrypted.rst | 85 +
MAINTAINERS | 9 +
drivers/crypto/mxs-dcp.c | 104 +-
include/keys/trusted_dcp.h| 11 +
include/soc/fsl/dcp.h | 17 +
security/keys/trusted-keys/Kconfig| 18 +-
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_core.c | 6 +-
security/keys/trusted-keys/trusted_dcp.c | 311 ++
10 files changed, 562 insertions(+), 14 deletions(-)
create mode 100644 include/keys/trusted_dcp.h
create mode 100644 include/soc/fsl/dcp.h
create mode 100644 security/keys/trusted-keys/trusted_dcp.c
--
2.35.3
Re: [PATCH 10/13] powerpc: Define KMSAN metadata address ranges for vmalloc and ioremap
Nicholas Miehlbradt writes: > Splits the vmalloc region into four. The first quarter is the new > vmalloc region, the second is used to store shadow metadata and the > third is used to store origin metadata. The fourth quarter is unused. > Do we support KMSAN for both hash and radix? If hash is not supported can we then using radix.h for these changes? > Do the same for the ioremap region. > > Module data is stored in the vmalloc region so alias the modules > metadata addresses to the respective vmalloc metadata addresses. Define > MODULES_VADDR and MODULES_END to the start and end of the vmalloc > region. > > Since MODULES_VADDR was previously only defined on ppc32 targets checks > for if this macro is defined need to be updated to include > defined(CONFIG_PPC32). -aneesh
Re: [PATCH 09/13] powerpc: Disable KMSAN checks on functions which walk the stack
Nicholas Miehlbradt writes: > Functions which walk the stack read parts of the stack which cannot be > instrumented by KMSAN e.g. the backchain. Disable KMSAN sanitization of > these functions to prevent false positives. > Is the annotation needed to avoid uninitialized access check when reading parts of the stack? Can you provide a false positive example for the commit message? -aneesh
Re: [PATCH 1/2] powerpc/locking: implement this_cpu_cmpxchg local API
On Mon, Dec 11, 2023 at 10:40:38PM +1100, Michael Ellerman wrote: > Hi Luming Yu, > > Luming Yu writes: > > ppc appears to have already supported cmpxchg-local atomic semantics > > that is defined by the kernel convention of the feature. > > Add this_cpu_cmpxchg ppc local for the performance benefit of arch > > sepcific implementation than asm-generic c verison of the locking API. > > Implementing this has been suggested before but it wasn't clear that it > was actually going to perform better than the generic version. Thanks for the info. To me, it is a news. : -) I will check if any web search engine could serve me well to find it out. > > On 64-bit we have interrupt soft masking, so disabling interrupts is > relatively cheap. So the generic this_cpu_cmpxhg using irq disable just > becomes a few loads & stores, no atomic ops required. something like this just popped up in my first try with a p8 test kvm on a c1000 powernv8 platform? I'm not sure the soft lockup is relevant to the interrupt soft masking, but I will find it out for sure. : -) [ 460.217669] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1] [ 460.217742] Modules linked in: [ 460.217828] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GWL N 6.7.0-rc5+ #5 [ 460.217915] Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf05 of:SLOF,git-6b6c16 pSeries [ 460.217999] NIP: c003e0ec LR: c003e414 CTR: [ 460.218074] REGS: c4797788 TRAP: 0900 Tainted: GWL N (6.7.0-rc5+) [ 460.218151] MSR: 82009033 CR: 24042442 XER: [ 460.218342] CFAR: IRQMASK: 0 [ 460.218342] GPR00: c003e414 c4797760 c1583b00 c4797758 [ 460.218342] GPR04: 0004 c4ccf51c c224e510 [ 460.218342] GPR08: 4002 0049 c457b280 0015000b00170038 [ 460.218342] GPR12: 00340030003a0010 c2f4 0008 c4ccf4fc [ 460.218342] GPR16: 7586 c40f45c0 c4ddd080 c40f45c0 [ 460.218342] GPR20: 0008 0024 0004 c4ccf4fc [ 460.218342] GPR24: 003f 0001 0001 c4cc6e7e [ 460.218342] GPR28: fcff 0002 fcff 0003 [ 460.219187] NIP [c003e0ec] __replay_soft_interrupts+0x3c/0x160 [ 460.219286] LR [c003e414] arch_local_irq_restore+0x174/0x1a0 [ 460.219365] Call Trace: [ 460.219400] [c4797760] [c003e150] __replay_soft_interrupts+0xa0/0x160 (unreliable) [ 460.219515] [c4797910] [c003e414] arch_local_irq_restore+0x174/0x1a0 [ 460.219612] [c4797950] [c0a155c4] get_random_u32+0xb4/0x140 [ 460.219699] [c47979a0] [c08b1ae0] get_rcw_we+0x138/0x274 [ 460.219781] [c4797a30] [c208d4bc] test_rslib_init+0x8b8/0xb70 [ 460.219877] [c4797c40] [c000fb80] do_one_initcall+0x60/0x390 [ 460.219965] [c4797d10] [c2004a18] kernel_init_freeable+0x32c/0x3dc [ 460.220059] [c4797de0] [c00102a4] kernel_init+0x34/0x1b0 [ 460.220141] [c4797e50] [c000cf14] ret_from_kernel_user_thread+0x14/0x1c [ 460.220229] --- interrupt: 0 at 0x0 [ 460.220291] Code: 6000 7c0802a6 f8010010 f821fe51 e92d0c78 f92101a8 3920 38610028 892d0933 61290040 992d0933 48043a3d <6000> 3920 e9410130 f9210160 [ 460.955369] Testing (23,15)_64 code... > > In contrast implementing it using __cmpxchg_local() will use > ldarx/stdcx etc. which will be more expensive. > > Have you done any performance measurements? Yes, I'm looking for resource to track the perf changes (positive or negative) in this corner for this patch set being proposed again. > > It probably is a bit fishy that we don't mask PMU interrupts vs > this_cpu_cmpxchg() etc., but I don't think it's actually a bug given the > few places using this_cpu_cmpxchg(). Though I could be wrong about that. I will try to understand the concern and will try to come up with a patch update, iff the performance number from the change could look reasonable and promising. > > > diff --git a/arch/powerpc/include/asm/percpu.h > > b/arch/powerpc/include/asm/percpu.h > > index 8e5b7d0b851c..ceab5df6e7ab 100644 > > --- a/arch/powerpc/include/asm/percpu.h > > +++ b/arch/powerpc/include/asm/percpu.h > > @@ -18,5 +18,22 @@ > > #include > > > > #include > > +#include > > +#ifdef this_cpu_cmpxchg_1 > > +#undef this_cpu_cmpxchg_1 > > If we need to undef then I think something has gone wrong with the > header inclusion order, the model should be that the arch defines what > it has and the generic code provides fallbacks if the arch didn't define > anything. > > > +#define this_cpu_cmpxchg_1(pcp, oval, nval) > > __cmpxchg_local(raw_cpu_ptr(&(pcp)), oval, nval, 1) > >
Re: [RFC PATCH 2/3] powerpc/fadump: pass additional parameters to dump capture kernel
Hello Hari,
On 06/12/23 01:48, Hari Bathini wrote:
For fadump case, passing additional parameters to dump capture kernel
helps in minimizing the memory footprint for it and also provides the
flexibility to disable components/modules, like hugepages, that are
hindering the boot process of the special dump capture environment.
Set up a dedicated parameter area to be passed to the capture kernel.
This area type is defined as RTAS_FADUMP_PARAM_AREA. Sysfs attribute
'/sys/kernel/fadump/bootargs_append' is exported to the userspace to
specify the additional parameters to be passed to the capture kernel
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump-internal.h | 3 +
arch/powerpc/kernel/fadump.c | 80
arch/powerpc/platforms/powernv/opal-fadump.c | 6 +-
arch/powerpc/platforms/pseries/rtas-fadump.c | 35 -
arch/powerpc/platforms/pseries/rtas-fadump.h | 11 ++-
5 files changed, 126 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-internal.h
index b3956c400519..81629226b15f 100644
--- a/arch/powerpc/include/asm/fadump-internal.h
+++ b/arch/powerpc/include/asm/fadump-internal.h
@@ -97,6 +97,8 @@ struct fw_dump {
unsigned long cpu_notes_buf_vaddr;
unsigned long cpu_notes_buf_size;
+ unsigned long param_area;
+
/*
* Maximum size supported by firmware to copy from source to
* destination address per entry.
@@ -111,6 +113,7 @@ struct fw_dump {
unsigned long dump_active:1;
unsigned long dump_registered:1;
unsigned long nocma:1;
+ unsigned long param_area_supported:1;
struct fadump_ops *ops;
};
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 757681658dda..98f089747ac9 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1470,6 +1470,7 @@ static ssize_t mem_reserved_show(struct kobject *kobj,
return sprintf(buf, "%ld\n", fw_dump.reserve_dump_area_size);
}
+
static ssize_t registered_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1477,6 +1478,43 @@ static ssize_t registered_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.dump_registered);
}
+static ssize_t bootargs_append_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", (char *)__va(fw_dump.param_area));
+}
+
+static ssize_t bootargs_append_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ char *params;
+
+ if (!fw_dump.fadump_enabled || fw_dump.dump_active)
+ return -EPERM;
+
+ if (count >= COMMAND_LINE_SIZE)
+ return -EINVAL;
+
+ /*
+* Fail here instead of handling this scenario with
+* some silly workaround in capture kernel.
+*/
+ if (saved_command_line_len + count >= COMMAND_LINE_SIZE) {
+ pr_err("Appending parameters exceeds cmdline size!\n");
+ return -ENOSPC;
+ }
+
+ params = __va(fw_dump.param_area);
+ strscpy_pad(params, buf, COMMAND_LINE_SIZE);
+ /* Remove newline character at the end. */
+ if (params[count-1] == '\n')
+ params[count-1] = '\0';
+
+ return count;
+}
+
static ssize_t registered_store(struct kobject *kobj,
struct kobj_attribute *attr,
const char *buf, size_t count)
@@ -1535,6 +1573,7 @@ static struct kobj_attribute release_attr =
__ATTR_WO(release_mem);
static struct kobj_attribute enable_attr = __ATTR_RO(enabled);
static struct kobj_attribute register_attr = __ATTR_RW(registered);
static struct kobj_attribute mem_reserved_attr = __ATTR_RO(mem_reserved);
+static struct kobj_attribute bootargs_append_attr = __ATTR_RW(bootargs_append);
static struct attribute *fadump_attrs[] = {
_attr.attr,
@@ -1611,6 +1650,46 @@ static void __init fadump_init_files(void)
return;
}
+/*
+ * Reserve memory to store additional parameters to be passed
+ * for fadump/capture kernel.
+ */
+static void fadump_setup_param_area(void)
+{
+ phys_addr_t range_start, range_end;
+
+ if (!fw_dump.param_area_supported || fw_dump.dump_active)
+ return;
+
+ /* This memory can't be used by PFW or bootloader as it is shared
across kernels */
+ if (radix_enabled()) {
+ /*
+* Anywhere in the upper half should be good enough as all
memory
+* is accessible in real mode.
+*/
+ range_start = memblock_end_of_DRAM() / 2;
+ range_end =
Re: [RFC PATCH 1/3] powerpc/pseries/fadump: add support for multiple boot memory regions
Hello Hari,
On 06/12/23 01:48, Hari Bathini wrote:
From: Sourabh Jain
Currently, fadump on pseries assumes a single boot memory region even
though f/w supports more than one boot memory region. Add support for
more boot memory regions to make the implementation flexible for any
enhancements that introduce other region types. For this, rtas memory
structure for fadump is updated to have multiple boot memory regions
instead of just one. Additionally, methods responsible for creating
the fadump memory structure during both the first and second kernel
boot have been modified to take these multiple boot memory regions
into account. Also, a new callback has been added to the fadump_ops
structure to get the maximum boot memory regions supported by the
platform.
Signed-off-by: Sourabh Jain
Signed-off-by: Hari Bathini
---
arch/powerpc/include/asm/fadump-internal.h | 2 +-
arch/powerpc/kernel/fadump.c | 27 +-
arch/powerpc/platforms/powernv/opal-fadump.c | 8 +
arch/powerpc/platforms/pseries/rtas-fadump.c | 258 ---
arch/powerpc/platforms/pseries/rtas-fadump.h | 26 +-
5 files changed, 199 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/include/asm/fadump-internal.h
index 27f9e11eda28..b3956c400519 100644
--- a/arch/powerpc/include/asm/fadump-internal.h
+++ b/arch/powerpc/include/asm/fadump-internal.h
@@ -129,6 +129,7 @@ struct fadump_ops {
struct seq_file *m);
void(*fadump_trigger)(struct fadump_crash_info_header *fdh,
const char *msg);
+ int (*fadump_max_boot_mem_rgns)(void);
};
/* Helper functions */
@@ -136,7 +137,6 @@ s32 __init fadump_setup_cpu_notes_buf(u32 num_cpus);
void fadump_free_cpu_notes_buf(void);
u32 *__init fadump_regs_to_elf_notes(u32 *buf, struct pt_regs *regs);
void __init fadump_update_elfcore_header(char *bufp);
-bool is_fadump_boot_mem_contiguous(void);
bool is_fadump_reserved_mem_contiguous(void);
#else /* !CONFIG_PRESERVE_FA_DUMP */
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index d14eda1e8589..757681658dda 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -222,28 +222,6 @@ static bool is_fadump_mem_area_contiguous(u64 d_start, u64
d_end)
return ret;
}
-/*
- * Returns true, if there are no holes in boot memory area,
- * false otherwise.
- */
-bool is_fadump_boot_mem_contiguous(void)
-{
- unsigned long d_start, d_end;
- bool ret = false;
- int i;
-
- for (i = 0; i < fw_dump.boot_mem_regs_cnt; i++) {
- d_start = fw_dump.boot_mem_addr[i];
- d_end = d_start + fw_dump.boot_mem_sz[i];
-
- ret = is_fadump_mem_area_contiguous(d_start, d_end);
- if (!ret)
- break;
- }
-
- return ret;
-}
-
/*
* Returns true, if there are no holes in reserved memory area,
* false otherwise.
@@ -389,10 +367,11 @@ static unsigned long __init get_fadump_area_size(void)
static int __init add_boot_mem_region(unsigned long rstart,
unsigned long rsize)
{
+ int max_boot_mem_rgns = fw_dump.ops->fadump_max_boot_mem_rgns();
int i = fw_dump.boot_mem_regs_cnt++;
- if (fw_dump.boot_mem_regs_cnt > FADUMP_MAX_MEM_REGS) {
- fw_dump.boot_mem_regs_cnt = FADUMP_MAX_MEM_REGS;
+ if (fw_dump.boot_mem_regs_cnt > max_boot_mem_rgns) {
+ fw_dump.boot_mem_regs_cnt = max_boot_mem_rgns;
return 0;
}
diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c b/arch/powerpc/platforms/powernv/opal-fadump.c
index 964f464b1b0e..fa26c21a08d9 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -615,6 +615,13 @@ static void opal_fadump_trigger(struct
fadump_crash_info_header *fdh,
pr_emerg("No backend support for MPIPL!\n");
}
+/* FADUMP_MAX_MEM_REGS or lower */
+static int opal_fadump_max_boot_mem_rgns(void)
+{
+ return FADUMP_MAX_MEM_REGS;
+
Nitpick: we can get rid of the above blank line.
- Sourabh
+}
+
static struct fadump_ops opal_fadump_ops = {
.fadump_init_mem_struct = opal_fadump_init_mem_struct,
.fadump_get_metadata_size = opal_fadump_get_metadata_size,
@@ -627,6 +634,7 @@ static struct fadump_ops opal_fadump_ops = {
.fadump_process = opal_fadump_process,
.fadump_region_show = opal_fadump_region_show,
.fadump_trigger = opal_fadump_trigger,
+ .fadump_max_boot_mem_rgns = opal_fadump_max_boot_mem_rgns,
};
void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.c
b/arch/powerpc/platforms/pseries/rtas-fadump.c
index
