* [PATCH v7 2/6] powerpc/book3s64/radix: Add H_RPT_INVALIDATE pgsize encodings to mmu_psize_def
From: Bharata B Rao @ 2021-05-05 15:46 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: farosas, aneesh.kumar, npiggin, Bharata B Rao, david
In-Reply-To: <20210505154642.178702-1-bharata@linux.ibm.com>
Add a field to mmu_psize_def to store the page size encodings
of H_RPT_INVALIDATE hcall. Initialize this while scanning the radix
AP encodings. This will be used when invalidating with required
page size encoding in the hcall.
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
arch/powerpc/mm/book3s64/radix_pgtable.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
index eace8c3f7b0a..c02f42d1031e 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -19,6 +19,7 @@ struct mmu_psize_def {
int penc[MMU_PAGE_COUNT]; /* HPTE encoding */
unsigned int tlbiel; /* tlbiel supported for that page size */
unsigned long avpnm; /* bits to mask out in AVPN in the HPTE */
+ unsigned long h_rpt_pgsize; /* H_RPT_INVALIDATE page size encoding */
union {
unsigned long sllp; /* SLB L||LP (exact mask to use in slbmte) */
unsigned long ap; /* Ap encoding used by PowerISA 3.0 */
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 5fef8db3b463..637db10d841e 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -486,6 +486,7 @@ static int __init radix_dt_scan_page_sizes(unsigned long node,
def = &mmu_psize_defs[idx];
def->shift = shift;
def->ap = ap;
+ def->h_rpt_pgsize = psize_to_rpti_pgsize(idx);
}
/* needed ? */
@@ -560,9 +561,13 @@ void __init radix__early_init_devtree(void)
*/
mmu_psize_defs[MMU_PAGE_4K].shift = 12;
mmu_psize_defs[MMU_PAGE_4K].ap = 0x0;
+ mmu_psize_defs[MMU_PAGE_4K].h_rpt_pgsize =
+ psize_to_rpti_pgsize(MMU_PAGE_4K);
mmu_psize_defs[MMU_PAGE_64K].shift = 16;
mmu_psize_defs[MMU_PAGE_64K].ap = 0x5;
+ mmu_psize_defs[MMU_PAGE_64K].h_rpt_pgsize =
+ psize_to_rpti_pgsize(MMU_PAGE_64K);
}
/*
--
2.26.2
^ permalink raw reply related
* [PATCH v7 0/6] Support for H_RPT_INVALIDATE in PowerPC KVM
From: Bharata B Rao @ 2021-05-05 15:46 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: farosas, aneesh.kumar, npiggin, Bharata B Rao, david
This patchset adds support for the new hcall H_RPT_INVALIDATE
and replaces the nested tlb flush calls with this new hcall
if support for the same exists.
Changes in v7:
-------------
- Fixed a bug where LPID of nested guest was being fetched
wrongly in the process scoped invalidation part of nested
guest exit handler.
(In kvmppc_nested_h_rpt_invalidate() of patch 4/6)
- Moved the movement of RIC_FLUSH_ definitions to appropriate
patch.
v6: https://lore.kernel.org/linuxppc-dev/20210311083939.595568-1-bharata@linux.ibm.com/
Aneesh Kumar K.V (1):
KVM: PPC: Book3S HV: Fix comments of H_RPT_INVALIDATE arguments
Bharata B Rao (5):
powerpc/book3s64/radix: Add H_RPT_INVALIDATE pgsize encodings to
mmu_psize_def
KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE
KVM: PPC: Book3S HV: Nested support in H_RPT_INVALIDATE
KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability
KVM: PPC: Book3S HV: Use H_RPT_INVALIDATE in nested KVM
Documentation/virt/kvm/api.rst | 18 +++
arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
.../include/asm/book3s/64/tlbflush-radix.h | 4 +
arch/powerpc/include/asm/hvcall.h | 4 +-
arch/powerpc/include/asm/kvm_book3s.h | 3 +
arch/powerpc/include/asm/mmu_context.h | 11 ++
arch/powerpc/kvm/book3s_64_mmu_radix.c | 27 +++-
arch/powerpc/kvm/book3s_hv.c | 106 ++++++++++++
arch/powerpc/kvm/book3s_hv_nested.c | 116 ++++++++++++-
arch/powerpc/kvm/powerpc.c | 3 +
arch/powerpc/mm/book3s64/radix_pgtable.c | 5 +
arch/powerpc/mm/book3s64/radix_tlb.c | 152 +++++++++++++++++-
include/uapi/linux/kvm.h | 1 +
13 files changed, 438 insertions(+), 13 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH v7 1/6] KVM: PPC: Book3S HV: Fix comments of H_RPT_INVALIDATE arguments
From: Bharata B Rao @ 2021-05-05 15:46 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: farosas, aneesh.kumar, npiggin, Bharata B Rao, david
In-Reply-To: <20210505154642.178702-1-bharata@linux.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
The type values H_RPTI_TYPE_PRT and H_RPTI_TYPE_PAT indicate
invalidating the caching of process and partition scoped entries
respectively.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/include/asm/hvcall.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 443050906018..f9927a1545ea 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -413,9 +413,9 @@
#define H_RPTI_TYPE_NESTED 0x0001 /* Invalidate nested guest partition-scope */
#define H_RPTI_TYPE_TLB 0x0002 /* Invalidate TLB */
#define H_RPTI_TYPE_PWC 0x0004 /* Invalidate Page Walk Cache */
-/* Invalidate Process Table Entries if H_RPTI_TYPE_NESTED is clear */
+/* Invalidate caching of Process Table Entries if H_RPTI_TYPE_NESTED is clear */
#define H_RPTI_TYPE_PRT 0x0008
-/* Invalidate Partition Table Entries if H_RPTI_TYPE_NESTED is set */
+/* Invalidate caching of Partition Table Entries if H_RPTI_TYPE_NESTED is set */
#define H_RPTI_TYPE_PAT 0x0008
#define H_RPTI_TYPE_ALL (H_RPTI_TYPE_TLB | H_RPTI_TYPE_PWC | \
H_RPTI_TYPE_PRT)
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Michal Suchánek @ 2021-05-05 15:23 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210503110713.751840-1-npiggin@gmail.com>
Hello,
looks like the ABI flags are not correctly applied when cross-compiling.
While building natively success of BTFIDS depends on the kernel ABI but
when cross-compiling success of BTFIDS depends on the default toolchain
ABI.
It's problem independent of this patch - the problem exists both before
and after.
Thanks
Michal
On Mon, May 03, 2021 at 09:07:13PM +1000, Nicholas Piggin wrote:
> Provide an option to build big-endian kernels using the ELFv2 ABI. This
> works on GCC only so far, although it is rumored to work with clang
> that's not been tested yet.
>
> This can give big-endian kernels some useful advantages of the ELFv2 ABI
> (e.g., less stack usage, -mprofile-kernel, better compatibility with bpf
> tools).
>
> BE+ELFv2 is not officially supported by the GNU toolchain, but it works
> fine in testing and has been used by some userspace for some time (e.g.,
> Void Linux).
>
> Tested-by: Michal Suchánek <msuchanek@suse.de>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
>
> I didn't add the -mprofile-kernel change but I think it would be a good
> one that can be merged independently if it works.
>
> Since v2:
> - Rebased, tweaked changelog.
> - Changed ELF_V2 to ELF_V2_ABI in config options, to be clearer.
>
> Since v1:
> - Improved the override flavour name suggested by Segher.
> - Improved changelog wording.
>
> arch/powerpc/Kconfig | 22 ++++++++++++++++++++++
> arch/powerpc/Makefile | 18 ++++++++++++------
> arch/powerpc/boot/Makefile | 4 +++-
> arch/powerpc/kernel/vdso64/Makefile | 13 +++++++++++++
> drivers/crypto/vmx/Makefile | 8 ++++++--
> drivers/crypto/vmx/ppc-xlate.pl | 10 ++++++----
> 6 files changed, 62 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1e6230bea09d..d3f78d3d574d 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -160,6 +160,7 @@ config PPC
> select ARCH_WEAK_RELEASE_ACQUIRE
> select BINFMT_ELF
> select BUILDTIME_TABLE_SORT
> + select PPC64_BUILD_ELF_V2_ABI if PPC64 && CPU_LITTLE_ENDIAN
> select CLONE_BACKWARDS
> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> select DMA_OPS if PPC64
> @@ -568,6 +569,27 @@ config KEXEC_FILE
> config ARCH_HAS_KEXEC_PURGATORY
> def_bool KEXEC_FILE
>
> +config PPC64_BUILD_ELF_V2_ABI
> + bool
> +
> +config PPC64_BUILD_BIG_ENDIAN_ELF_V2_ABI
> + bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)"
> + depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
> + depends on CC_IS_GCC && LD_VERSION >= 22400
> + default n
> + select PPC64_BUILD_ELF_V2_ABI
> + help
> + This builds the kernel image using the "Power Architecture 64-Bit ELF
> + V2 ABI Specification", which has a reduced stack overhead and faster
> + function calls. This internal kernel ABI option does not affect
> + userspace compatibility.
> +
> + The V2 ABI is standard for 64-bit little-endian, but for big-endian
> + it is less well tested by kernel and toolchain. However some distros
> + build userspace this way, and it can produce a functioning kernel.
> +
> + This requires GCC and binutils 2.24 or newer.
> +
> config RELOCATABLE
> bool "Build a relocatable kernel"
> depends on PPC64 || (FLATMEM && (44x || FSL_BOOKE))
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 3212d076ac6a..b90b5cb799aa 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -91,10 +91,14 @@ endif
>
> ifdef CONFIG_PPC64
> ifndef CONFIG_CC_IS_CLANG
> -cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
> -cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mcall-aixdesc)
> -aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
> -aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
> +ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> +cflags-y += $(call cc-option,-mabi=elfv2)
> +aflags-y += $(call cc-option,-mabi=elfv2)
> +else
> +cflags-y += $(call cc-option,-mabi=elfv1)
> +cflags-y += $(call cc-option,-mcall-aixdesc)
> +aflags-y += $(call cc-option,-mabi=elfv1)
> +endif
> endif
> endif
>
> @@ -142,15 +146,17 @@ endif
>
> CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
> ifndef CONFIG_CC_IS_CLANG
> -ifdef CONFIG_CPU_LITTLE_ENDIAN
> -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
> +ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> +CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
> else
> +# Keep these in synch with arch/powerpc/kernel/vdso64/Makefile
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
> endif
> endif
> +
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc))
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 2b8da923ceca..be84a72f8258 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -40,6 +40,9 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>
> ifdef CONFIG_PPC64_BOOT_WRAPPER
> BOOTCFLAGS += -m64
> +ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> +BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
> +endif
> else
> BOOTCFLAGS += -m32
> endif
> @@ -50,7 +53,6 @@ ifdef CONFIG_CPU_BIG_ENDIAN
> BOOTCFLAGS += -mbig-endian
> else
> BOOTCFLAGS += -mlittle-endian
> -BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
> endif
>
> BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
> diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
> index 2813e3f98db6..d783c07e558f 100644
> --- a/arch/powerpc/kernel/vdso64/Makefile
> +++ b/arch/powerpc/kernel/vdso64/Makefile
> @@ -25,6 +25,19 @@ KCOV_INSTRUMENT := n
> UBSAN_SANITIZE := n
> KASAN_SANITIZE := n
>
> +# Always build vdso64 with ELFv1 ABI for BE kernels
> +ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> +ifdef CONFIG_CPU_BIG_ENDIAN
> +KBUILD_CFLAGS := $(filter-out -mabi=elfv2,$(KBUILD_CFLAGS))
> +KBUILD_AFLAGS := $(filter-out -mabi=elfv2,$(KBUILD_AFLAGS))
> +
> +# These are derived from arch/powerpc/Makefile
> +KBUILD_CFLAGS += $(call cc-option,-mabi=elfv1)
> +KBUILD_CFLAGS += $(call cc-option,-mcall-aixdesc)
> +KBUILD_AFLAGS += $(call cc-option,-mabi=elfv1)
> +endif
> +endif
> +
> ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
> -Wl,-soname=linux-vdso64.so.1 -Wl,--hash-style=both
> asflags-y := -D__VDSO64__ -s
> diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
> index 709670d2b553..d9ccf9fc3483 100644
> --- a/drivers/crypto/vmx/Makefile
> +++ b/drivers/crypto/vmx/Makefile
> @@ -5,18 +5,22 @@ vmx-crypto-objs := vmx.o aesp8-ppc.o ghashp8-ppc.o aes.o aes_cbc.o aes_ctr.o aes
> ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> override flavour := linux-ppc64le
> else
> +ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> +override flavour := linux-ppc64-elfv2
> +else
> override flavour := linux-ppc64
> endif
> +endif
>
> quiet_cmd_perl = PERL $@
> cmd_perl = $(PERL) $(<) $(flavour) > $(@)
>
> targets += aesp8-ppc.S ghashp8-ppc.S
>
> -$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
> +$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl $(src)/ppc-xlate.pl FORCE
> $(call if_changed,perl)
>
> -$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
> +$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl $(src)/ppc-xlate.pl FORCE
> $(call if_changed,perl)
>
> clean-files := aesp8-ppc.S ghashp8-ppc.S
> diff --git a/drivers/crypto/vmx/ppc-xlate.pl b/drivers/crypto/vmx/ppc-xlate.pl
> index 36db2ef09e5b..b583898c11ae 100644
> --- a/drivers/crypto/vmx/ppc-xlate.pl
> +++ b/drivers/crypto/vmx/ppc-xlate.pl
> @@ -9,6 +9,8 @@ open STDOUT,">$output" || die "can't open $output: $!";
>
> my %GLOBALS;
> my $dotinlocallabels=($flavour=~/linux/)?1:0;
> +my $elfv2abi=(($flavour =~ /linux-ppc64le/) or ($flavour =~ /linux-ppc64-elfv2/))?1:0;
> +my $dotfunctions=($elfv2abi=~1)?0:1;
>
> ################################################################
> # directives which need special treatment on different platforms
> @@ -40,7 +42,7 @@ my $globl = sub {
> };
> my $text = sub {
> my $ret = ($flavour =~ /aix/) ? ".csect\t.text[PR],7" : ".text";
> - $ret = ".abiversion 2\n".$ret if ($flavour =~ /linux.*64le/);
> + $ret = ".abiversion 2\n".$ret if ($elfv2abi);
> $ret;
> };
> my $machine = sub {
> @@ -56,8 +58,8 @@ my $size = sub {
> if ($flavour =~ /linux/)
> { shift;
> my $name = shift; $name =~ s|^[\.\_]||;
> - my $ret = ".size $name,.-".($flavour=~/64$/?".":"").$name;
> - $ret .= "\n.size .$name,.-.$name" if ($flavour=~/64$/);
> + my $ret = ".size $name,.-".($dotfunctions?".":"").$name;
> + $ret .= "\n.size .$name,.-.$name" if ($dotfunctions);
> $ret;
> }
> else
> @@ -142,7 +144,7 @@ my $vmr = sub {
>
> # Some ABIs specify vrsave, special-purpose register #256, as reserved
> # for system use.
> -my $no_vrsave = ($flavour =~ /linux-ppc64le/);
> +my $no_vrsave = ($elfv2abi);
> my $mtspr = sub {
> my ($f,$idx,$ra) = @_;
> if ($idx == 256 && $no_vrsave) {
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH v4] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-05-05 14:39 UTC (permalink / raw)
To: Nathan Lynch
Cc: Tyrel Datwyler, linuxppc-dev, paulus, linux-kernel,
Aneesh Kumar K . V
In-Reply-To: <87bl9qf7xk.fsf@linux.ibm.com>
Le 05/05/2021 à 00:30, Nathan Lynch a écrit :
> Hi Laurent,
Hi Nathan,
Thanks for your review.
> Bear with me while I work through the commit message:
>
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
>> updated by the hypervisor in the case the NUMA topology of the LPAR's
>> memory is updated.
>
> Yes, the RTAS functions ibm,update-nodes and ibm,update-properties,
> which the OS invokes after resuming, may bring in updated properties
> under the ibm,dynamic-reconfiguration-memory node, including the
> ibm,associativity-lookup-arrays property.
>
>> This is caught by the kernel,
>
> "Caught" makes me think this is an error condition, as in catching an
> exception. I guess "handled" better conveys your meaning?
ok
>
>> but the memory's node is updated because
>> there is no way to move a memory block between nodes.
>
> "The memory's node" refers the ibm,dynamic-reconfiguration-memory DT
> node, yes? Or is it referring to Linux's NUMA nodes? ("move a memory
> block between nodes" in your statement here refers to Linux's NUMA
> nodes, that much is clear to me.)
>
> I am failing to follow the cause->effect relationship stated. True,
> changing a block's node assignment while it's in use isn't safe. I don't
> see why that implies that "the memory's node is updated"? In fact this
> seems contradictory.
>
> This statement makes more sense to me if I change it to "the memory's
> node is _not_ updated" -- is this what you intended?
Correct, I dropped the 'not' word here ;)
>
>> If later a memory block is added or removed, drmem_update_dt() is called
>> and it is overwriting the DT node to match the added or removed LMB.
>
> I understand this, but I will expand on it.
>
> dlpar_memory()
> -> dlpar_memory_add_by_count()
> -> dlpar_add_lmb()
> -> update_lmb_associativity_index()
> ... lmb->aa_index = <value>
> -> drmem_update_dt()
>
> update_lmb_associativity_index() retrieves the firmware description of
> the new block, and sets the aa_index of the matching entry in the
> drmem_info array to the value matching the firmware description.
>
> Then, drmem_update_dt() walks the drmem_info array and synthesizes a new
> /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory-v2 property based
> on the recently updated information in that array.
Yes
>
>> But the LMB's associativity node has not been updated after the DT
>> node update and thus the node is overwritten by the Linux's topology
>> instead of the hypervisor one.
>
> So, an example of the problem is:
>
> 1. VM migrates. On resume, ibm,associativity-lookup-arrays is changed
> via ibm,update-properties. Entries in the drmem_info array remain
> unchanged, with aa_index values that correspond to the source
> system's ibm,associativity-lookup-arrays property, now inaccessible.
>
> 2. A memory block is added. We look up the new block's entry in the
> drmem_info array, and set the aa_index to the value matching the
> current ibm,associativity-lookup-arrays.
>
> 3. Then, the ibm,associativity-lookup-arrays property is completely
> regenerated from the drmem_info array, which reflects a mixture of
> information from the source and destination systems.
>
> Do I understand correctly?
Yes
>
>
>> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
>> updated to force an update of the LMB's associativity. However, ignore the
>> call to that hook when the update has been triggered by drmem_update_dt().
>> Because, in that case, the LMB tree has been used to set the DT property
>> and thus it doesn't need to be updated back. Since drmem_update_dt() is
>> called under the protection of the device_hotplug_lock and the hook is
>> called in the same context, use a simple boolean variable to detect that
>> call.
>
> This strikes me as almost a revert of e978a3ccaa71 ("powerpc/pseries:
> remove obsolete memory hotplug DT notifier code").
Not really identical to reverting e978a3ccaa71, here only the aa_index of the
LMB is updated, everything else is kept in place. I don't try to apply the
memory layout's changes, just updating the in use LMB's aa_index field.
The only matching point with the code reverted by the commit you mentioned would
be the use of a global variable in_drmem_update instead of the previous
rtas_hp_event to prevent the LMB tree to be updated again during memory hot plug
event.
> I'd rather avoid smuggling through global state information that ought
> to be passed in function parameters, if it should be passed around at
> all. Despite having (IMO) relatively simple responsibilities, this code
> is difficult to change and review; adding this property makes it
> worse. If the structure of the code is pushing us toward this kind of
> compromise, then the code probably needs more fundamental changes.
>
> I'm probably forgetting something -- can anyone remind me why we need an
> array of these:
>
> struct drmem_lmb {
> u64 base_addr;
> u32 drc_index;
> u32 aa_index;
> u32 flags;
> };
>
> which is just a less efficient representation of what's already in the
> device tree? If we got rid of it, would this problem disappear?
I don't think this is right for the moment, at first, we should robustify the
DLPAR and LPM operations.
^ permalink raw reply
* [PATCH v2 2/2] powerpc/paca: Remove mm_ctx_id and mm_ctx_slb_addr_limit
From: Christophe Leroy @ 2021-05-05 14:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1c80981548dc0c4f145109cdd473022c1aad8d2b.1620223302.git.christophe.leroy@csgroup.eu>
mm_ctx_id and mm_ctx_slb_addr_limit are not used anymore.
Remove them.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/paca.h | 2 --
arch/powerpc/kernel/paca.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index ec18ac818e3a..ecc8d792a431 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -149,11 +149,9 @@ struct paca_struct {
#endif /* CONFIG_PPC_BOOK3E */
#ifdef CONFIG_PPC_BOOK3S
- mm_context_id_t mm_ctx_id;
#ifdef CONFIG_PPC_MM_SLICES
unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
- unsigned long mm_ctx_slb_addr_limit;
#else
u16 mm_ctx_user_psize;
u16 mm_ctx_sllp;
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 7f5aae3c387d..9bd30cac852b 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -346,10 +346,8 @@ void copy_mm_to_paca(struct mm_struct *mm)
#ifdef CONFIG_PPC_BOOK3S
mm_context_t *context = &mm->context;
- get_paca()->mm_ctx_id = context->id;
#ifdef CONFIG_PPC_MM_SLICES
VM_BUG_ON(!mm_ctx_slb_addr_limit(context));
- get_paca()->mm_ctx_slb_addr_limit = mm_ctx_slb_addr_limit(context);
memcpy(&get_paca()->mm_ctx_low_slices_psize, mm_ctx_low_slices(context),
LOW_SLICE_ARRAY_SZ);
memcpy(&get_paca()->mm_ctx_high_slices_psize, mm_ctx_high_slices(context),
--
2.25.0
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/asm-offset: Remove unused items
From: Christophe Leroy @ 2021-05-05 14:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
Following PACA related items are not used anymore by ASM code:
PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX.
Following items are also not used anymore:
SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP, TI_FLAGS, TI_PREEMPT,
DCACHEL1BLOCKSPERPAGE, ICACHEL1BLOCKSIZE, ICACHEL1LOGBLOCKSIZE,
ICACHEL1BLOCKSPERPAGE, STACK_REGS_KUAP, KVM_NEED_FLUSH, KVM_FWNMI,
VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR and
PPC_DBELL_MSGTYPE.
Remove all of them.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/asm-offsets.c | 52 +------------------------------
1 file changed, 1 insertion(+), 51 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 28af4efb4587..0480f4006e0c 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -87,10 +87,7 @@ int main(void)
#endif
#endif
OFFSET(MMCONTEXTID, mm_struct, context.id);
-#ifdef CONFIG_PPC64
- DEFINE(SIGSEGV, SIGSEGV);
- DEFINE(NMI_MASK, NMI_MASK);
-#else
+#ifdef CONFIG_PPC32
#ifdef CONFIG_PPC_RTAS
OFFSET(RTAS_SP, thread_struct, rtas_sp);
#endif
@@ -154,18 +151,12 @@ int main(void)
OFFSET(THREAD_USED_SPE, thread_struct, used_spe);
#endif /* CONFIG_SPE */
#endif /* CONFIG_PPC64 */
-#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- OFFSET(THREAD_DBCR0, thread_struct, debug.dbcr0);
-#endif
#ifdef CONFIG_KVM_BOOK3S_32_HANDLER
OFFSET(THREAD_KVM_SVCPU, thread_struct, kvm_shadow_vcpu);
#endif
#if defined(CONFIG_KVM) && defined(CONFIG_BOOKE)
OFFSET(THREAD_KVM_VCPU, thread_struct, kvm_vcpu);
#endif
-#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_PPC_KUAP)
- OFFSET(KUAP, thread_struct, kuap);
-#endif
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
OFFSET(PACATMSCRATCH, paca_struct, tm_scratch);
@@ -185,19 +176,12 @@ int main(void)
sizeof(struct pt_regs) + 16);
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
- OFFSET(TI_FLAGS, thread_info, flags);
OFFSET(TI_LOCAL_FLAGS, thread_info, local_flags);
- OFFSET(TI_PREEMPT, thread_info, preempt_count);
#ifdef CONFIG_PPC64
OFFSET(DCACHEL1BLOCKSIZE, ppc64_caches, l1d.block_size);
OFFSET(DCACHEL1LOGBLOCKSIZE, ppc64_caches, l1d.log_block_size);
- OFFSET(DCACHEL1BLOCKSPERPAGE, ppc64_caches, l1d.blocks_per_page);
- OFFSET(ICACHEL1BLOCKSIZE, ppc64_caches, l1i.block_size);
- OFFSET(ICACHEL1LOGBLOCKSIZE, ppc64_caches, l1i.log_block_size);
- OFFSET(ICACHEL1BLOCKSPERPAGE, ppc64_caches, l1i.blocks_per_page);
/* paca */
- DEFINE(PACA_SIZE, sizeof(struct paca_struct));
OFFSET(PACAPACAINDEX, paca_struct, paca_index);
OFFSET(PACAPROCSTART, paca_struct, cpu_start);
OFFSET(PACAKSAVE, paca_struct, kstack);
@@ -212,15 +196,6 @@ int main(void)
OFFSET(PACAIRQSOFTMASK, paca_struct, irq_soft_mask);
OFFSET(PACAIRQHAPPENED, paca_struct, irq_happened);
OFFSET(PACA_FTRACE_ENABLED, paca_struct, ftrace_enabled);
-#ifdef CONFIG_PPC_BOOK3S
- OFFSET(PACACONTEXTID, paca_struct, mm_ctx_id);
-#ifdef CONFIG_PPC_MM_SLICES
- OFFSET(PACALOWSLICESPSIZE, paca_struct, mm_ctx_low_slices_psize);
- OFFSET(PACAHIGHSLICEPSIZE, paca_struct, mm_ctx_high_slices_psize);
- OFFSET(PACA_SLB_ADDR_LIMIT, paca_struct, mm_ctx_slb_addr_limit);
- DEFINE(MMUPSIZEDEFSIZE, sizeof(struct mmu_psize_def));
-#endif /* CONFIG_PPC_MM_SLICES */
-#endif
#ifdef CONFIG_PPC_BOOK3E
OFFSET(PACAPGD, paca_struct, pgd);
@@ -241,21 +216,9 @@ int main(void)
#endif /* CONFIG_PPC_BOOK3E */
#ifdef CONFIG_PPC_BOOK3S_64
- OFFSET(PACASLBCACHE, paca_struct, slb_cache);
- OFFSET(PACASLBCACHEPTR, paca_struct, slb_cache_ptr);
- OFFSET(PACASTABRR, paca_struct, stab_rr);
- OFFSET(PACAVMALLOCSLLP, paca_struct, vmalloc_sllp);
-#ifdef CONFIG_PPC_MM_SLICES
- OFFSET(MMUPSIZESLLP, mmu_psize_def, sllp);
-#else
- OFFSET(PACACONTEXTSLLP, paca_struct, mm_ctx_sllp);
-#endif /* CONFIG_PPC_MM_SLICES */
OFFSET(PACA_EXGEN, paca_struct, exgen);
OFFSET(PACA_EXMC, paca_struct, exmc);
OFFSET(PACA_EXNMI, paca_struct, exnmi);
-#ifdef CONFIG_PPC_PSERIES
- OFFSET(PACALPPACAPTR, paca_struct, lppaca_ptr);
-#endif
OFFSET(PACA_SLBSHADOWPTR, paca_struct, slb_shadow_ptr);
OFFSET(SLBSHADOW_STACKVSID, slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid);
OFFSET(SLBSHADOW_STACKESID, slb_shadow, save_area[SLB_NUM_BOLTED - 1].esid);
@@ -264,9 +227,7 @@ int main(void)
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
OFFSET(PACA_PMCINUSE, paca_struct, pmcregs_in_use);
#endif
- OFFSET(LPPACA_DTLIDX, lppaca, dtl_idx);
OFFSET(LPPACA_YIELDCOUNT, lppaca, yield_count);
- OFFSET(PACA_DTL_RIDX, paca_struct, dtl_ridx);
#endif /* CONFIG_PPC_BOOK3S_64 */
OFFSET(PACAEMERGSP, paca_struct, emergency_sp);
#ifdef CONFIG_PPC_BOOK3S_64
@@ -343,10 +304,6 @@ int main(void)
STACK_PT_REGS_OFFSET(STACK_REGS_AMR, amr);
STACK_PT_REGS_OFFSET(STACK_REGS_IAMR, iamr);
#endif
-#ifdef CONFIG_PPC_KUAP
- STACK_PT_REGS_OFFSET(STACK_REGS_KUAP, kuap);
-#endif
-
#if defined(CONFIG_PPC32)
#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
@@ -482,11 +439,9 @@ int main(void)
OFFSET(KVM_HOST_LPID, kvm, arch.host_lpid);
OFFSET(KVM_HOST_LPCR, kvm, arch.host_lpcr);
OFFSET(KVM_HOST_SDR1, kvm, arch.host_sdr1);
- OFFSET(KVM_NEED_FLUSH, kvm, arch.need_tlb_flush.bits);
OFFSET(KVM_ENABLED_HCALLS, kvm, arch.enabled_hcalls);
OFFSET(KVM_VRMA_SLB_V, kvm, arch.vrma_slb_v);
OFFSET(KVM_RADIX, kvm, arch.radix);
- OFFSET(KVM_FWNMI, kvm, arch.fwnmi_enabled);
OFFSET(KVM_SECURE_GUEST, kvm, arch.secure_guest);
OFFSET(VCPU_DSISR, kvm_vcpu, arch.shregs.dsisr);
OFFSET(VCPU_DAR, kvm_vcpu, arch.shregs.dar);
@@ -514,7 +469,6 @@ int main(void)
OFFSET(VCPU_DAWRX1, kvm_vcpu, arch.dawrx1);
OFFSET(VCPU_CIABR, kvm_vcpu, arch.ciabr);
OFFSET(VCPU_HFLAGS, kvm_vcpu, arch.hflags);
- OFFSET(VCPU_DEC, kvm_vcpu, arch.dec);
OFFSET(VCPU_DEC_EXPIRES, kvm_vcpu, arch.dec_expires);
OFFSET(VCPU_PENDING_EXC, kvm_vcpu, arch.pending_exceptions);
OFFSET(VCPU_CEDED, kvm_vcpu, arch.ceded);
@@ -525,7 +479,6 @@ int main(void)
OFFSET(VCPU_MMCRA, kvm_vcpu, arch.mmcra);
OFFSET(VCPU_MMCRS, kvm_vcpu, arch.mmcrs);
OFFSET(VCPU_PMC, kvm_vcpu, arch.pmc);
- OFFSET(VCPU_SPMC, kvm_vcpu, arch.spmc);
OFFSET(VCPU_SIAR, kvm_vcpu, arch.siar);
OFFSET(VCPU_SDAR, kvm_vcpu, arch.sdar);
OFFSET(VCPU_SIER, kvm_vcpu, arch.sier);
@@ -646,10 +599,8 @@ int main(void)
HSTATE_FIELD(HSTATE_HWTHREAD_STATE, hwthread_state);
HSTATE_FIELD(HSTATE_KVM_VCPU, kvm_vcpu);
HSTATE_FIELD(HSTATE_KVM_VCORE, kvm_vcore);
- HSTATE_FIELD(HSTATE_XICS_PHYS, xics_phys);
HSTATE_FIELD(HSTATE_XIVE_TIMA_PHYS, xive_tima_phys);
HSTATE_FIELD(HSTATE_XIVE_TIMA_VIRT, xive_tima_virt);
- HSTATE_FIELD(HSTATE_SAVED_XIRR, saved_xirr);
HSTATE_FIELD(HSTATE_HOST_IPI, host_ipi);
HSTATE_FIELD(HSTATE_PTID, ptid);
HSTATE_FIELD(HSTATE_FAKE_SUSPEND, fake_suspend);
@@ -757,7 +708,6 @@ int main(void)
#endif
DEFINE(PPC_DBELL_SERVER, PPC_DBELL_SERVER);
- DEFINE(PPC_DBELL_MSGTYPE, PPC_DBELL_MSGTYPE);
#ifdef CONFIG_PPC_8xx
DEFINE(VIRT_IMMR_BASE, (u64)__fix_to_virt(FIX_IMMR_BASE));
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Michal Suchánek @ 2021-05-05 13:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andreas Schwab, Nicholas Piggin
In-Reply-To: <87tunh8jum.fsf@mpe.ellerman.id.au>
On Wed, May 05, 2021 at 10:07:29PM +1000, Michael Ellerman wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
> > On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
> >> Should this add a tag to the module vermagic?
> >
> > Would the modues link even if the vermagic was not changed?
>
> Most modules will require some symbols from the kernel, and those will
> be dot symbols, which won't resolve.
>
> But there are a few small modules that don't rely on any kernel symbols,
> which can load.
>
> > I suppose something like this might do it.
>
> It would, but I feel like we should be handling this at the ELF level.
> ie. we don't allow loading modules with a different ELF machine type, so
> neither should we allow loading a module with the wrong ELF ABI.
>
> And you can build the kernel without MODVERSIONS, so relying on
> MODVERSIONS still leaves a small exposure (same kernel version
> with/without ELFv2).
>
> I don't see an existing hook that would do what we want. There's
> elf_check_arch(), but that also applies to userspace binaries, which is
> not what we want.
>
> Maybe something like below.
Yes, that looks better.
Thanks
Michal
>
> cheers
>
>
> diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
> index 857d9ff24295..d0e9368982d8 100644
> --- a/arch/powerpc/include/asm/module.h
> +++ b/arch/powerpc/include/asm/module.h
> @@ -83,5 +83,28 @@ static inline int module_finalize_ftrace(struct module *mod, const Elf_Shdr *sec
> }
> #endif
>
> +#ifdef CONFIG_PPC64
> +static inline bool elf_check_module_arch(Elf_Ehdr *hdr)
> +{
> + unsigned long flags;
> +
> + if (!elf_check_arch(hdr))
> + return false;
> +
> + flags = hdr->e_flags & 0x3;
> +
> +#ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
> + if (flags == 2)
> + return true;
> +#else
> + if (flags < 2)
> + return true;
> +#endif
> + return false;
> +}
> +
> +#define elf_check_module_arch elf_check_module_arch
> +#endif /* CONFIG_PPC64 */
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_MODULE_H */
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 9e09d11ffe5b..fdc042a84562 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -13,6 +13,11 @@
> * must be implemented by each architecture.
> */
>
> +// Allow arch to optionally do additional checking of module ELF header
> +#ifndef elf_check_module_arch
> +#define elf_check_module_arch elf_check_arch
> +#endif
> +
> /* Adjust arch-specific sections. Return 0 on success. */
> int module_frob_arch_sections(Elf_Ehdr *hdr,
> Elf_Shdr *sechdrs,
> diff --git a/kernel/module.c b/kernel/module.c
> index b5dd92e35b02..c71889107226 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2941,7 +2941,7 @@ static int elf_validity_check(struct load_info *info)
>
> if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
> || info->hdr->e_type != ET_REL
> - || !elf_check_arch(info->hdr)
> + || !elf_check_module_arch(info->hdr)
> || info->hdr->e_shentsize != sizeof(Elf_Shdr))
> return -ENOEXEC;
>
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-05 12:43 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <c103a1a5-4a22-1738-1d65-3314a4457a0d@csgroup.eu>
On 04 May 2021 at 05:17pm, Christophe Leroy wrote:
> Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :
>> On 04 May 2021 at 04:41pm Christophe Leroy wrote:
>>> Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
>>>> On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:
>>>>> On 04 May 2021 at 11:49am, Christophe Leroy wrote:
>>>>>
>>>>> I am bisecting currently.
>>>>>
>>>>> $ git bisect start -- arch/powerpc
>>>>> $ git bisect good 887f3ceb51cd3~
>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>> OK, there is another issue after the second bisecting step. The
>>>> boot stops after loading the dtb and uImage file. I can't solve 2
>>>> issues with bisecting at the same time.
>>>
>>> In that case, you can use 'git bisect skip' to skip the one that is
>>> not booting at all.
>> In my point of view 'git bisect skip' isn't a good idea because I
>> will not find out if the skipped commit is good or bad and maybe the
>> first bad commit.
>
> The second problem may be completely unrelated to the first one so it
> could work.
>
> In any case, if 'git bisect' finds out that the bad commit is in the
> middle of a skipped area, it will tell you. So I think it is worth it.
>
> The second solution could be to first focus on that 'boot stops after
> loading problem' and try to find out which commit introduces the bug,
> then which one fixes it. But it may not be necessary.
>
> Other solution, as you were thinking that the conversion of 'booke' to
> C interrupt entry/exit, you can also try around that: See if d738ee8
> has the problem and 2e2a441 doesn't have the problem.
>
> If so, you can bisect between those two commits (There are 8 commits
> inbetween).
Hi Christophe,
I am bisecting with skipping the boot issue currently. Unfortunately it
seems there is another bug. I had to skip two times because the kernel
didn't compile.
Bisecting log:
1) git bisect start -- arch/powerpc
2) git bisect good 887f3ceb51cd3~
3) git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
4) git bisect bad
5) git bisect skip It stopped after loading the dtb and uImage. Maybe a
third bug.
6) git bisect skip It stopped after loading the dtb and uImage.
7) git bisect skip It stopped after loading the dtb and uImage.
8) git bisect skip It stopped after loading the dtb and uImage.
9) git bisect skip It stopped after loading the dtb and uImage.
([472724111f0f72042deb6a9dcee9578e5398a1a1] powerpc/iommu: Enable
remaining IOMMU Pagesizes present in LoPAR)
10) git bisect skip It stopped after loading the dtb and uImage.
([ceff77efa4f8d9f02d8442171b325d3b7068fe5e] powerpc/64e/interrupt: Use
new interrupt context tracking scheme)
11) git bisect skip It stopped after loading the dtb and uImage.
([7dcc37b3eff97379b194adb17eb9a8270512dd1d] powerpc/xive: Map one IPI
interrupt per node)
12) git bisect skip It stopped after loading the dtb and uImage.
([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt:
reconcile irq soft-mask state in C)
13) git bisect skip It didn't compile.
Error messages:
arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1199: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
([fd6db2892ebaa1383a93b4a609c65b96e615510a] powerpc/xive: Modernize
XIVE-IPI domain with an 'alloc' handler)
14) git bisect skip It stopped after loading the dtb and uImage.
([0c2472de23aea5ce9139a3e887191925759d1259] powerpc/64e/interrupt: use
new interrupt return)
15) git bisect skip It stopped after loading the dtb and uImage.
([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt:
reconcile irq soft-mask state in C)
16) git bisect skip It didn't compile.
Error messages:
arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1199: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
([14b3c9d24a7a5c274a9df27d245516f466d3bc5f] powerpc/syscalls: switch to
generic syscalltbl.sh)
17) git bisect skip It stopped after loading the dtb and uImage.
([08a022ad3dfafc7e33d4529015e14bb75179cacc] powerpc/powernv/memtrace:
Allow mmaping trace buffers)
18) git bisect skip It stopped after loading the dtb and uImage.
([e5d56763525e65417dad0d46572b234fa0008e40] powerpc/rtas: rename
RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE)
19) git bisect skip It stopped after loading the dtb and uImage.
([98db179a78dd8379e9d2cbfc3f00224168a9344c] powerpc/64s: power4 nap
fixup in C)
20) git bisect skip It stopped after loading the dtb and uImage.
([c13ff6f3251318f5e1ff5b1a6d05f76996db672a] powerpc/rtas: improve
ppc_rtas_rmo_buf_show documentation)
Should I continue bisecting?
You can find the other steps (21 and higher) here:
https://forum.hyperion-entertainment.com/viewtopic.php?p=53103#p53103
Thanks,
Christian
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Segher Boessenkool @ 2021-05-05 12:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <875yzyae55.fsf@mpe.ellerman.id.au>
On Tue, May 04, 2021 at 10:15:34PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Mon, May 03, 2021 at 10:51:41AM +1000, Nicholas Piggin wrote:
> >> then ELF ABIv2 is more explanatory about it being an abi change
> >> rather than base elf change, even if it's not the "correct" name.
> >
> > I very much disagree. "ELF ABIv2" is completely meaningless.
>
> Except:
>
> $ readelf -h /bin/true
> ELF Header:
> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: DYN (Shared object file)
> Machine: PowerPC64
> Version: 0x1
> Entry point address: 0x1990
> Start of program headers: 64 (bytes into file)
> Start of section headers: 66176 (bytes into file)
> Flags: 0x2, abiv2
> ^^^^^
Ha :-)
This can also print "abiv1" or even "abiv0", btw:
case EM_PPC64:
if (e_flags & EF_PPC64_ABI)
{
char abi[] = ", abiv0";
abi[6] += e_flags & EF_PPC64_ABI;
strcat (buf, abi);
}
break;
This is only in readelf, and the main audience for readelf is the people
who know all details about what means what already. But, do you have a
suggestion for better output here?
Segher
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks
From: Nicholas Piggin @ 2021-05-05 12:15 UTC (permalink / raw)
To: kvm-ppc
Cc: kvm, Sean Christopherson, Nicholas Piggin, Bharata B Rao,
Aneesh Kumar K . V, Paolo Bonzini, linuxppc-dev
Commit b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier
callbacks") causes unmap_gfn_range and age_gfn callbacks to only work
on the first gfn in the range. It also makes the aging callbacks call
into both radix and hash aging functions for radix guests. Fix this.
Add warnings for the single-gfn calls that have been converted to range
callbacks, in case they ever receieve ranges greater than 1.
Fixes: b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")
Reported-by: Bharata B Rao <bharata@linux.ibm.com>
Tested-by: Bharata B Rao <bharata@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
The e500 change in that commit also looks suspicious, why is it okay
to remove kvm_flush_remote_tlbs() there? Also is the the change from
returning false to true intended?
Thanks,
Nick
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 46 ++++++++++++++++++--------
arch/powerpc/kvm/book3s_64_mmu_radix.c | 5 ++-
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index a6e9a5585e61..e6b53c6e21e3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -210,7 +210,7 @@ extern void kvmppc_free_pgtable_radix(struct kvm *kvm, pgd_t *pgd,
unsigned int lpid);
extern int kvmppc_radix_init(void);
extern void kvmppc_radix_exit(void);
-extern bool kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+extern void kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
unsigned long gfn);
extern bool kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
unsigned long gfn);
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index b7bd9ca040b8..2d9193cd73be 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -795,7 +795,7 @@ static void kvmppc_unmap_hpte(struct kvm *kvm, unsigned long i,
}
}
-static bool kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
+static void kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
unsigned long gfn)
{
unsigned long i;
@@ -829,15 +829,21 @@ static bool kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
unlock_rmap(rmapp);
__unlock_hpte(hptep, be64_to_cpu(hptep[0]));
}
- return false;
}
bool kvm_unmap_gfn_range_hv(struct kvm *kvm, struct kvm_gfn_range *range)
{
- if (kvm_is_radix(kvm))
- return kvm_unmap_radix(kvm, range->slot, range->start);
+ gfn_t gfn;
+
+ if (kvm_is_radix(kvm)) {
+ for (gfn = range->start; gfn < range->end; gfn++)
+ kvm_unmap_radix(kvm, range->slot, gfn);
+ } else {
+ for (gfn = range->start; gfn < range->end; gfn++)
+ kvm_unmap_rmapp(kvm, range->slot, range->start);
+ }
- return kvm_unmap_rmapp(kvm, range->slot, range->start);
+ return false;
}
void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
@@ -924,10 +930,18 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
bool kvm_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
{
- if (kvm_is_radix(kvm))
- kvm_age_radix(kvm, range->slot, range->start);
+ gfn_t gfn;
+ bool ret = false;
- return kvm_age_rmapp(kvm, range->slot, range->start);
+ if (kvm_is_radix(kvm)) {
+ for (gfn = range->start; gfn < range->end; gfn++)
+ ret |= kvm_age_radix(kvm, range->slot, gfn);
+ } else {
+ for (gfn = range->start; gfn < range->end; gfn++)
+ ret |= kvm_age_rmapp(kvm, range->slot, gfn);
+ }
+
+ return ret;
}
static bool kvm_test_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
@@ -965,18 +979,24 @@ static bool kvm_test_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
bool kvm_test_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
{
- if (kvm_is_radix(kvm))
- kvm_test_age_radix(kvm, range->slot, range->start);
+ WARN_ON(range->start + 1 != range->end);
- return kvm_test_age_rmapp(kvm, range->slot, range->start);
+ if (kvm_is_radix(kvm))
+ return kvm_test_age_radix(kvm, range->slot, range->start);
+ else
+ return kvm_test_age_rmapp(kvm, range->slot, range->start);
}
bool kvm_set_spte_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
{
+ WARN_ON(range->start + 1 != range->end);
+
if (kvm_is_radix(kvm))
- return kvm_unmap_radix(kvm, range->slot, range->start);
+ kvm_unmap_radix(kvm, range->slot, range->start);
+ else
+ kvm_unmap_rmapp(kvm, range->slot, range->start);
- return kvm_unmap_rmapp(kvm, range->slot, range->start);
+ return false;
}
static int vcpus_running(struct kvm *kvm)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index ec4f58fa9f5a..d909c069363e 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -993,7 +993,7 @@ int kvmppc_book3s_radix_page_fault(struct kvm_vcpu *vcpu,
}
/* Called with kvm->mmu_lock held */
-bool kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+void kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
unsigned long gfn)
{
pte_t *ptep;
@@ -1002,14 +1002,13 @@ bool kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE) {
uv_page_inval(kvm->arch.lpid, gpa, PAGE_SHIFT);
- return false;
+ return;
}
ptep = find_kvm_secondary_pte(kvm, gpa, &shift);
if (ptep && pte_present(*ptep))
kvmppc_unmap_pte(kvm, ptep, gpa, shift, memslot,
kvm->arch.lpid);
- return false;
}
/* Called with kvm->mmu_lock held */
--
2.23.0
^ permalink raw reply related
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Michael Ellerman @ 2021-05-05 12:07 UTC (permalink / raw)
To: Michal Suchánek, Andreas Schwab; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210503143841.GN6564@kitsune.suse.cz>
Michal Suchánek <msuchanek@suse.de> writes:
> On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
>> Should this add a tag to the module vermagic?
>
> Would the modues link even if the vermagic was not changed?
Most modules will require some symbols from the kernel, and those will
be dot symbols, which won't resolve.
But there are a few small modules that don't rely on any kernel symbols,
which can load.
> I suppose something like this might do it.
It would, but I feel like we should be handling this at the ELF level.
ie. we don't allow loading modules with a different ELF machine type, so
neither should we allow loading a module with the wrong ELF ABI.
And you can build the kernel without MODVERSIONS, so relying on
MODVERSIONS still leaves a small exposure (same kernel version
with/without ELFv2).
I don't see an existing hook that would do what we want. There's
elf_check_arch(), but that also applies to userspace binaries, which is
not what we want.
Maybe something like below.
cheers
diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
index 857d9ff24295..d0e9368982d8 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -83,5 +83,28 @@ static inline int module_finalize_ftrace(struct module *mod, const Elf_Shdr *sec
}
#endif
+#ifdef CONFIG_PPC64
+static inline bool elf_check_module_arch(Elf_Ehdr *hdr)
+{
+ unsigned long flags;
+
+ if (!elf_check_arch(hdr))
+ return false;
+
+ flags = hdr->e_flags & 0x3;
+
+#ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+ if (flags == 2)
+ return true;
+#else
+ if (flags < 2)
+ return true;
+#endif
+ return false;
+}
+
+#define elf_check_module_arch elf_check_module_arch
+#endif /* CONFIG_PPC64 */
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MODULE_H */
diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
index 9e09d11ffe5b..fdc042a84562 100644
--- a/include/linux/moduleloader.h
+++ b/include/linux/moduleloader.h
@@ -13,6 +13,11 @@
* must be implemented by each architecture.
*/
+// Allow arch to optionally do additional checking of module ELF header
+#ifndef elf_check_module_arch
+#define elf_check_module_arch elf_check_arch
+#endif
+
/* Adjust arch-specific sections. Return 0 on success. */
int module_frob_arch_sections(Elf_Ehdr *hdr,
Elf_Shdr *sechdrs,
diff --git a/kernel/module.c b/kernel/module.c
index b5dd92e35b02..c71889107226 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2941,7 +2941,7 @@ static int elf_validity_check(struct load_info *info)
if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
|| info->hdr->e_type != ET_REL
- || !elf_check_arch(info->hdr)
+ || !elf_check_module_arch(info->hdr)
|| info->hdr->e_shentsize != sizeof(Elf_Shdr))
return -ENOEXEC;
^ permalink raw reply related
* [PATCH 2/2] powerpc/32s: Convert switch_mmu_context() to C
From: Christophe Leroy @ 2021-05-05 9:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f20b416b3ef2064b3cad1f0f87ceb7cb8c59d309.1620206886.git.christophe.leroy@csgroup.eu>
switch_mmu_context() does things that can easily be done in C.
For updating user segments, we have update_user_segments().
As mentionned in commit b5efec00b671 ("powerpc/32s: Move KUEP
locking/unlocking in C"), update_user_segments() has the loop
unrolled which is a significant performance gain.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/asm-offsets.c | 5 ---
arch/powerpc/kernel/head_book3s_32.S | 53 +-------------------------
arch/powerpc/mm/book3s32/mmu_context.c | 27 +++++++++++++
3 files changed, 28 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 28af4efb4587..459829805177 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -86,7 +86,6 @@ int main(void)
OFFSET(PACA_CANARY, paca_struct, canary);
#endif
#endif
- OFFSET(MMCONTEXTID, mm_struct, context.id);
#ifdef CONFIG_PPC64
DEFINE(SIGSEGV, SIGSEGV);
DEFINE(NMI_MASK, NMI_MASK);
@@ -368,10 +367,6 @@ int main(void)
#endif
#endif
-#ifndef CONFIG_PPC64
- OFFSET(MM_PGD, mm_struct, pgd);
-#endif /* ! CONFIG_PPC64 */
-
/* About the CPU features table */
OFFSET(CPU_SPEC_FEATURES, cpu_spec, cpu_features);
OFFSET(CPU_SPEC_SETUP, cpu_spec, cpu_setup);
diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S
index 065178f19a3d..c1d2f0d1d6b2 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -1023,58 +1023,6 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_HPTE_TABLE)
mtspr SPRN_SRR1,r4
rfi
-/*
- * void switch_mmu_context(struct mm_struct *prev, struct mm_struct *next);
- *
- * Set up the segment registers for a new context.
- */
-_ENTRY(switch_mmu_context)
- lwz r3,MMCONTEXTID(r4)
- cmpwi cr0,r3,0
- blt- 4f
- mulli r3,r3,897 /* multiply context by skew factor */
- rlwinm r3,r3,4,8,27 /* VSID = (context & 0xfffff) << 4 */
-#ifdef CONFIG_PPC_KUEP
- oris r3, r3, SR_NX@h /* Set Nx */
-#endif
-#ifdef CONFIG_PPC_KUAP
- oris r3, r3, SR_KS@h /* Set Ks */
-#endif
- li r0,NUM_USER_SEGMENTS
- mtctr r0
-
-#ifdef CONFIG_BDI_SWITCH
- /* Context switch the PTE pointer for the Abatron BDI2000.
- * The PGDIR is passed as second argument.
- */
- lwz r4, MM_PGD(r4)
- lis r5, abatron_pteptrs@ha
- stw r4, abatron_pteptrs@l + 0x4(r5)
-#endif
-BEGIN_MMU_FTR_SECTION
-#ifndef CONFIG_BDI_SWITCH
- lwz r4, MM_PGD(r4)
-#endif
- tophys(r4, r4)
- rlwinm r4, r4, 4, 0xffff01ff
- mtspr SPRN_SDR1, r4
-END_MMU_FTR_SECTION_IFCLR(MMU_FTR_HPTE_TABLE)
- li r4,0
- isync
-3:
- mtsrin r3,r4
- addi r3,r3,0x111 /* next VSID */
- rlwinm r3,r3,0,8,3 /* clear out any overflow from VSID field */
- addis r4,r4,0x1000 /* address of next segment */
- bdnz 3b
- sync
- isync
- blr
-4: trap
- EMIT_BUG_ENTRY 4b,__FILE__,__LINE__,0
- blr
-EXPORT_SYMBOL(switch_mmu_context)
-
/*
* An undocumented "feature" of 604e requires that the v bit
* be cleared before changing BAT values.
@@ -1312,5 +1260,6 @@ swapper_pg_dir:
/* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
+ .globl abatron_pteptrs
abatron_pteptrs:
.space 8
diff --git a/arch/powerpc/mm/book3s32/mmu_context.c b/arch/powerpc/mm/book3s32/mmu_context.c
index 218996e40a8e..3fcac03b125f 100644
--- a/arch/powerpc/mm/book3s32/mmu_context.c
+++ b/arch/powerpc/mm/book3s32/mmu_context.c
@@ -111,3 +111,30 @@ void __init mmu_context_init(void)
context_map[0] = (1 << FIRST_CONTEXT) - 1;
next_mmu_context = FIRST_CONTEXT;
}
+
+void switch_mmu_context(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk)
+{
+ unsigned long id = next->context.id;
+ unsigned long val;
+
+ if (!id)
+ panic("mm_struct %p has no context ID", next);
+
+ isync();
+
+ val = ((id * 897) & 0xfffff) << 4;
+ if (IS_ENABLED(CONFIG_PPC_KUEP))
+ val |= SR_NX;
+ if (IS_ENABLED(CONFIG_PPC_KUAP))
+ val |= SR_KS;
+
+ update_user_segments(val);
+ mb(); /* sync */
+ isync();
+
+ if (IS_ENABLED(CONFIG_BDI_SWITCH))
+ abatron_pteptrs[1] = next->pgd;
+
+ if (!mmu_has_feature(MMU_FTR_HPTE_TABLE))
+ mtspr(SPRN_SDR1, rol32(__pa(next->pgd), 4) & 0xffff01ff);
+}
--
2.25.0
^ permalink raw reply related
* [PATCH 1/2] powerpc/32s: Refactor update of user segment registers
From: Christophe Leroy @ 2021-05-05 9:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
KUEP implements the update of user segment registers.
Move it into mmu-hash.h in order to use it from other places.
And inline kuep_lock() and kuep_unlock() and remove kuep.c
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 27 +++++++++++++
arch/powerpc/include/asm/kup.h | 11 ++++-
arch/powerpc/mm/book3s32/Makefile | 1 -
arch/powerpc/mm/book3s32/kuep.c | 40 -------------------
4 files changed, 36 insertions(+), 43 deletions(-)
delete mode 100644 arch/powerpc/mm/book3s32/kuep.c
diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
index b85f8e114a9c..cc0284bbac86 100644
--- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
@@ -102,6 +102,33 @@ extern s32 patch__hash_page_B, patch__hash_page_C;
extern s32 patch__flush_hash_A0, patch__flush_hash_A1, patch__flush_hash_A2;
extern s32 patch__flush_hash_B;
+#include <asm/reg.h>
+#include <asm/task_size_32.h>
+
+#define UPDATE_TWO_USER_SEGMENTS(n) do { \
+ if (TASK_SIZE > ((n) << 28)) \
+ mtsr(val1, (n) << 28); \
+ if (TASK_SIZE > (((n) + 1) << 28)) \
+ mtsr(val2, ((n) + 1) << 28); \
+ val1 = (val1 + 0x222) & 0xf0ffffff; \
+ val2 = (val2 + 0x222) & 0xf0ffffff; \
+} while (0)
+
+static __always_inline void update_user_segments(u32 val)
+{
+ int val1 = val;
+ int val2 = (val + 0x111) & 0xf0ffffff;
+
+ UPDATE_TWO_USER_SEGMENTS(0);
+ UPDATE_TWO_USER_SEGMENTS(2);
+ UPDATE_TWO_USER_SEGMENTS(4);
+ UPDATE_TWO_USER_SEGMENTS(6);
+ UPDATE_TWO_USER_SEGMENTS(8);
+ UPDATE_TWO_USER_SEGMENTS(10);
+ UPDATE_TWO_USER_SEGMENTS(12);
+ UPDATE_TWO_USER_SEGMENTS(14);
+}
+
#endif /* !__ASSEMBLY__ */
/* We happily ignore the smaller BATs on 601, we don't actually use
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index ec96232529ac..1da9fed5c321 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -47,8 +47,15 @@ static inline void setup_kuep(bool disabled) { }
#endif /* CONFIG_PPC_KUEP */
#if defined(CONFIG_PPC_KUEP) && defined(CONFIG_PPC_BOOK3S_32)
-void kuep_lock(void);
-void kuep_unlock(void);
+static inline void kuep_lock(void)
+{
+ update_user_segments(mfsr(0) | SR_NX);
+}
+
+static inline void kuep_unlock(void)
+{
+ update_user_segments(mfsr(0) & ~SR_NX);
+}
#else
static inline void kuep_lock(void) { }
static inline void kuep_unlock(void) { }
diff --git a/arch/powerpc/mm/book3s32/Makefile b/arch/powerpc/mm/book3s32/Makefile
index 7f0c8a78ba0c..446d9de88ce4 100644
--- a/arch/powerpc/mm/book3s32/Makefile
+++ b/arch/powerpc/mm/book3s32/Makefile
@@ -9,4 +9,3 @@ endif
obj-y += mmu.o mmu_context.o
obj-$(CONFIG_PPC_BOOK3S_603) += nohash_low.o
obj-$(CONFIG_PPC_BOOK3S_604) += hash_low.o tlb.o
-obj-$(CONFIG_PPC_KUEP) += kuep.o
diff --git a/arch/powerpc/mm/book3s32/kuep.c b/arch/powerpc/mm/book3s32/kuep.c
deleted file mode 100644
index 8ed1b8634839..000000000000
--- a/arch/powerpc/mm/book3s32/kuep.c
+++ /dev/null
@@ -1,40 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-
-#include <asm/kup.h>
-#include <asm/reg.h>
-#include <asm/task_size_32.h>
-#include <asm/mmu.h>
-
-#define KUEP_UPDATE_TWO_USER_SEGMENTS(n) do { \
- if (TASK_SIZE > ((n) << 28)) \
- mtsr(val1, (n) << 28); \
- if (TASK_SIZE > (((n) + 1) << 28)) \
- mtsr(val2, ((n) + 1) << 28); \
- val1 = (val1 + 0x222) & 0xf0ffffff; \
- val2 = (val2 + 0x222) & 0xf0ffffff; \
-} while (0)
-
-static __always_inline void kuep_update(u32 val)
-{
- int val1 = val;
- int val2 = (val + 0x111) & 0xf0ffffff;
-
- KUEP_UPDATE_TWO_USER_SEGMENTS(0);
- KUEP_UPDATE_TWO_USER_SEGMENTS(2);
- KUEP_UPDATE_TWO_USER_SEGMENTS(4);
- KUEP_UPDATE_TWO_USER_SEGMENTS(6);
- KUEP_UPDATE_TWO_USER_SEGMENTS(8);
- KUEP_UPDATE_TWO_USER_SEGMENTS(10);
- KUEP_UPDATE_TWO_USER_SEGMENTS(12);
- KUEP_UPDATE_TWO_USER_SEGMENTS(14);
-}
-
-void kuep_lock(void)
-{
- kuep_update(mfsr(0) | SR_NX);
-}
-
-void kuep_unlock(void)
-{
- kuep_update(mfsr(0) & ~SR_NX);
-}
--
2.25.0
^ permalink raw reply related
* Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Stephen Rothwell @ 2021-05-05 5:46 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Anshuman Khandual, Linux Kernel Mailing List,
Linux Next Mailing List, Andrew Morton, PowerPC
In-Reply-To: <87wnsd93rl.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
Hi Michael,
On Wed, 05 May 2021 14:57:18 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Urgh, I did check linux-next to see if that patch would conflict but
> didn't think it would conflict *that* badly.
Its not as bad as it looks, the akpm-current patches just added three
selects and just need to be put in the proper place.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage
From: Christoph Hellwig @ 2021-05-05 5:43 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm, qemu-devel, gregkh, linux-kernel, groug, qemu-ppc, daniel,
linux-api, linuxppc-dev, hch
In-Reply-To: <162014341432.3807030.11054087109120670135.stgit@omen>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v11 2/9] powerpc/lib/code-patching: Set up Strict RWX patching earlier
From: Jordan Niethe @ 2021-05-05 5:22 UTC (permalink / raw)
To: Christophe Leroy
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <d7f28ca3-bf4b-01c4-9706-b4f2061314b1@csgroup.eu>
On Thu, Apr 29, 2021 at 2:53 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> > setup_text_poke_area() is a late init call so it runs before
> > mark_rodata_ro() and after the init calls. This lets all the init code
> > patching simply write to their locations. In the future, kprobes is
> > going to allocate its instruction pages RO which means they will need
> > setup_text__poke_area() to have been already called for their code
> > patching. However, init_kprobes() (which allocates and patches some
> > instruction pages) is an early init call so it happens before
> > setup_text__poke_area().
> >
> > start_kernel() calls poking_init() before any of the init calls. On
> > powerpc, poking_init() is currently a nop. setup_text_poke_area() relies
> > on kernel virtual memory, cpu hotplug and per_cpu_areas being setup.
> > setup_per_cpu_areas(), boot_cpu_hotplug_init() and mm_init() are called
> > before poking_init().
> >
> > Turn setup_text_poke_area() into poking_init().
>
> I can't remember, maybe I already asked the question:
> Have you done some performance measurement or at least some performance analysis ?
No I don't think you have asked and it is a good question.
Here are some results on a Power9 (T2P9D01 REV 1.01) running powernv_defconfig
Timestamp at "Run /init as init process"
Before: ~1.059326
After: ~1.273105
Turning on more testing the difference is greater:
For example, turning on CONFIG_FTRACE_STARTUP_TEST
Timestamp at "Run /init as init process"
Before: ~7.176759
After: ~15.967576
Running with initcall_debug:
Before: initcall init_trace_selftests+0x0/0x1b4 returned 0 after 2880859 usecs
After: initcall init_trace_selftests+0x0/0x1b4 returned 0 after 10048828 usecs
So it does slow it down.
But it also might be a good thing for testing that these tests using
code patching now will use the same code path for patching that would
be used on a fully booted system.
>
> Christophe
>
> >
> > Reviewed-by: Russell Currey <ruscur@russell.cc>
> > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> > ---
> > v9: New to series
> > ---
> > arch/powerpc/lib/code-patching.c | 12 ++++--------
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> > index 870b30d9be2f..15296207e1ba 100644
> > --- a/arch/powerpc/lib/code-patching.c
> > +++ b/arch/powerpc/lib/code-patching.c
> > @@ -70,14 +70,11 @@ static int text_area_cpu_down(unsigned int cpu)
> > }
> >
> > /*
> > - * Run as a late init call. This allows all the boot time patching to be done
> > - * simply by patching the code, and then we're called here prior to
> > - * mark_rodata_ro(), which happens after all init calls are run. Although
> > - * BUG_ON() is rude, in this case it should only happen if ENOMEM, and we judge
> > - * it as being preferable to a kernel that will crash later when someone tries
> > - * to use patch_instruction().
> > + * Although BUG_ON() is rude, in this case it should only happen if ENOMEM, and
> > + * we judge it as being preferable to a kernel that will crash later when
> > + * someone tries to use patch_instruction().
> > */
> > -static int __init setup_text_poke_area(void)
> > +int __init poking_init(void)
> > {
> > BUG_ON(!cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
> > "powerpc/text_poke:online", text_area_cpu_up,
> > @@ -85,7 +82,6 @@ static int __init setup_text_poke_area(void)
> >
> > return 0;
> > }
> > -late_initcall(setup_text_poke_area);
> >
> > /*
> > * This can be called for kernel text or a module.
> >
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Michael Ellerman @ 2021-05-05 4:57 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Anshuman Khandual
In-Reply-To: <20210505113959.43340f19@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/powerpc/Kconfig
>
> between commit:
>
> c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects under CONFIG_PPC")
>
> from the powerpc tree and commits:
>
> fd7d5c273c43 ("mm: generalize HUGETLB_PAGE_SIZE_VARIABLE")
> 301ba77ae03c ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Urgh, I did check linux-next to see if that patch would conflict but
didn't think it would conflict *that* badly.
I guess I'll leave it for now, but I can drop it if necessary.
cheers
> diff --cc arch/powerpc/Kconfig
> index ab17a56c3d10,d4333049b813..000000000000
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -118,11 -118,10 +118,13 @@@ config PP
> # Please keep this list sorted alphabetically.
> #
> select ARCH_32BIT_OFF_T if PPC32
> + select ARCH_ENABLE_MEMORY_HOTPLUG
> + select ARCH_ENABLE_MEMORY_HOTREMOVE
> + select ARCH_HAS_COPY_MC if PPC64
> select ARCH_HAS_DEBUG_VIRTUAL
> + select ARCH_HAS_DEBUG_VM_PGTABLE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> + select ARCH_HAS_DMA_MAP_DIRECT if PPC_PSERIES
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FORTIFY_SOURCE
> select ARCH_HAS_GCOV_PROFILE_ALL
> @@@ -163,8 -162,9 +165,8 @@@
> select BUILDTIME_TABLE_SORT
> select CLONE_BACKWARDS
> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> - select DMA_OPS_BYPASS if PPC64
> select DMA_OPS if PPC64
> + select DMA_OPS_BYPASS if PPC64
> - select ARCH_HAS_DMA_MAP_DIRECT if PPC64 && PPC_PSERIES
> select DYNAMIC_FTRACE if FUNCTION_TRACER
> select EDAC_ATOMIC_SCRUB
> select EDAC_SUPPORT
> @@@ -182,15 -181,12 +184,15 @@@
> select GENERIC_STRNCPY_FROM_USER
> select GENERIC_STRNLEN_USER
> select GENERIC_TIME_VSYSCALL
> - select GENERIC_GETTIMEOFDAY
> + select GENERIC_VDSO_TIME_NS
> select HAVE_ARCH_AUDITSYSCALL
> - select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
> + select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> + select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
> select HAVE_ARCH_JUMP_LABEL
> + select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
> select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
> + select HAVE_ARCH_KFENCE if PPC32
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> @@@ -231,19 -227,23 +233,20 @@@
> select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
> select HAVE_MOD_ARCH_SPECIFIC
> select HAVE_NMI if PERF_EVENTS || (PPC64 && PPC_BOOK3S)
> - select HAVE_HARDLOCKUP_DETECTOR_ARCH if (PPC64 && PPC_BOOK3S)
> - select HAVE_OPTPROBES if PPC64
> + select HAVE_OPTPROBES
> select HAVE_PERF_EVENTS
> select HAVE_PERF_EVENTS_NMI if PPC64
> - select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI && !HAVE_HARDLOCKUP_DETECTOR_ARCH
> select HAVE_PERF_REGS
> select HAVE_PERF_USER_STACK_DUMP
> - select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
> - select MMU_GATHER_RCU_TABLE_FREE
> - select MMU_GATHER_PAGE_SIZE
> select HAVE_REGS_AND_STACK_ACCESS_API
> - select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN
> + select HAVE_RELIABLE_STACKTRACE
> + select HAVE_RSEQ
> select HAVE_SOFTIRQ_ON_OWN_STACK
> + select HAVE_STACKPROTECTOR if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
> + select HAVE_STACKPROTECTOR if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_VIRT_CPU_ACCOUNTING
> - select HAVE_IRQ_TIME_ACCOUNTING
> - select HAVE_RSEQ
> ++ select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
> select IOMMU_HELPER if PPC64
> select IRQ_DOMAIN
> select IRQ_FORCED_THREADING
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca
From: Christophe Leroy @ 2021-05-05 4:49 UTC (permalink / raw)
To: Nicholas Piggin, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <9b07e9c1-b004-a814-278b-c6a1f7b616e3@csgroup.eu>
Le 04/05/2021 à 12:40, Christophe Leroy a écrit :
>
>
> Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
>>> PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
>>> PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
>>> PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
>>> PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
>>> by ASM code.
>>
>> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>>
>> Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
>> TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH,
>> KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
>> PPC_DBELL_MSGTYPE I think. While we're cleaning it up.
>
> Yes, thanks for checking.
>
> I think we can safely remove KUAP.
>
> But we can't remove EXC_LVL_SIZE, it is used in kernel/head_booke.h which is probably included in
> head_44x.S and head_fsl_booke.S
DCACHEL1*BLOCKSIZE are also still used.
Christophe
>
> Christophe
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier
From: Nathan Lynch @ 2021-05-05 2:55 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, anton, npiggin, dja
In-Reply-To: <87zgx999pi.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> post_mobility_fixup() does cpus_read_unlock() before calling
>> pseries_setup_security_mitigations(), I think that will need to be
>> changed?
>
> I don't think so.
>
> I'm using stop_machine_cpuslocked() but that's because I'm a goose and
> forgot to switch to stop_machine() after I reworked the code to not take
> cpus_read_lock() by hand. I really shouldn't send patches after 11pm.
>
> I don't think it's important to keep the cpus lock held from where we
> take it in post_mobility_fixup(). If some CPUs come or go between there
> and here that's fine.
Yes, agreed.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier
From: Michael Ellerman @ 2021-05-05 2:48 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, anton, npiggin, dja
In-Reply-To: <878s4uf79w.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>> -void do_stf_barrier_fixups(enum stf_barrier_type types)
>> +static int __do_stf_barrier_fixups(void *data)
>> {
>> + enum stf_barrier_type types = (enum stf_barrier_type)data;
>> +
>> do_stf_entry_barrier_fixups(types);
>> do_stf_exit_barrier_fixups(types);
>> +
>> + return 0;
>> +}
>> +
>> +void do_stf_barrier_fixups(enum stf_barrier_type types)
>> +{
>> + /*
>> + * The call to the fallback entry flush, and the fallback/sync-ori exit
>> + * flush can not be safely patched in/out while other CPUs are executing
>> + * them. So call __do_stf_barrier_fixups() on one CPU while all other CPUs
>> + * spin in the stop machine core with interrupts hard disabled.
>> + */
>> + stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);
>
> Would it be preferable to avoid the explicit casts:
>
> stop_machine_cpuslocked(__do_stf_barrier_fixups, &types, NULL);
>
> ...
>
> static int __do_stf_barrier_fixups(void *data)
> {
> enum stf_barrier_type *types = data;
>
> do_stf_entry_barrier_fixups(*types);
> do_stf_exit_barrier_fixups(*types);
>
> ?
Yes.
That will also avoid the pesky issue of undefined behaviour :facepalm:
> post_mobility_fixup() does cpus_read_unlock() before calling
> pseries_setup_security_mitigations(), I think that will need to be
> changed?
I don't think so.
I'm using stop_machine_cpuslocked() but that's because I'm a goose and
forgot to switch to stop_machine() after I reworked the code to not take
cpus_read_lock() by hand. I really shouldn't send patches after 11pm.
I don't think it's important to keep the cpus lock held from where we
take it in post_mobility_fixup(). If some CPUs come or go between there
and here that's fine.
I'll send a v2.
cheers
^ permalink raw reply
* [powerpc:next-test] BUILD REGRESSION a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
From: kernel test robot @ 2021-05-05 2:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c powerpc/64s: Fix crashes when toggling entry flush barrier
Error/Warning reports:
https://lore.kernel.org/linuxppc-dev/202105050102.q3cYdXnk-lkp@intel.com
https://lore.kernel.org/linuxppc-dev/202105050231.wjhXNTzu-lkp@intel.com
Error/Warning in current branch:
arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Error/Warning ids grouped by kconfigs:
clang_recent_errors
`-- powerpc-randconfig-r022-20210503
|-- arch-powerpc-lib-feature-fixups.c:error:cast-to-smaller-integer-type-enum-l1d_flush_type-from-void-Werror-Wvoid-pointer-to-enum-cast
`-- arch-powerpc-lib-feature-fixups.c:error:cast-to-smaller-integer-type-enum-stf_barrier_type-from-void-Werror-Wvoid-pointer-to-enum-cast
elapsed time: 723m
configs tested: 154
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
arm mxs_defconfig
mips allyesconfig
mips maltaup_xpa_defconfig
arm viper_defconfig
arm imote2_defconfig
arm imx_v6_v7_defconfig
arm pcm027_defconfig
powerpc tqm8560_defconfig
powerpc akebono_defconfig
arm at91_dt_defconfig
arm vexpress_defconfig
arm multi_v7_defconfig
powerpc mpc836x_mds_defconfig
mips ar7_defconfig
powerpc asp8347_defconfig
sparc64 alldefconfig
mips e55_defconfig
mips vocore2_defconfig
powerpc icon_defconfig
powerpc socrates_defconfig
powerpc tqm5200_defconfig
sh sdk7780_defconfig
m68k atari_defconfig
m68k mvme147_defconfig
arm integrator_defconfig
ia64 tiger_defconfig
m68k bvme6000_defconfig
powerpc tqm8548_defconfig
m68k m5272c3_defconfig
mips ip22_defconfig
powerpc makalu_defconfig
powerpc powernv_defconfig
arm sama5_defconfig
arm spitz_defconfig
powerpc cell_defconfig
powerpc mvme5100_defconfig
sh sh7770_generic_defconfig
mips rbtx49xx_defconfig
sh se7343_defconfig
openrisc or1ksim_defconfig
nios2 10m50_defconfig
arm h3600_defconfig
powerpc lite5200b_defconfig
h8300 defconfig
arm zeus_defconfig
powerpc mpc837x_mds_defconfig
powerpc ppa8548_defconfig
arm pxa3xx_defconfig
mips rm200_defconfig
arc haps_hs_defconfig
sh se7712_defconfig
arm collie_defconfig
powerpc mgcoge_defconfig
mips allmodconfig
riscv nommu_k210_sdcard_defconfig
arm sunxi_defconfig
arm colibri_pxa300_defconfig
sh sh7710voipgw_defconfig
sh sh7785lcr_defconfig
mips maltaaprp_defconfig
arm gemini_defconfig
arm spear6xx_defconfig
parisc allyesconfig
m68k stmark2_defconfig
sh se7780_defconfig
powerpc adder875_defconfig
mips nlm_xlp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64 randconfig-a014-20210504
x86_64 randconfig-a015-20210504
x86_64 randconfig-a012-20210504
x86_64 randconfig-a013-20210504
x86_64 randconfig-a011-20210504
x86_64 randconfig-a016-20210504
i386 randconfig-a015-20210504
i386 randconfig-a013-20210504
i386 randconfig-a016-20210504
i386 randconfig-a014-20210504
i386 randconfig-a012-20210504
i386 randconfig-a011-20210504
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a001-20210504
x86_64 randconfig-a003-20210504
x86_64 randconfig-a005-20210504
x86_64 randconfig-a002-20210504
x86_64 randconfig-a006-20210504
x86_64 randconfig-a004-20210504
x86_64 randconfig-a014-20210503
x86_64 randconfig-a015-20210503
x86_64 randconfig-a012-20210503
x86_64 randconfig-a011-20210503
x86_64 randconfig-a013-20210503
x86_64 randconfig-a016-20210503
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS c6b05f4e233cc666f003e9fe68b2f765952875a9
From: kernel test robot @ 2021-05-05 2:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: c6b05f4e233cc666f003e9fe68b2f765952875a9 powerpc/kconfig: Restore alphabetic order of the selects under CONFIG_PPC
elapsed time: 723m
configs tested: 137
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
arm mxs_defconfig
mips allyesconfig
mips maltaup_xpa_defconfig
arm viper_defconfig
arm imote2_defconfig
arm imx_v6_v7_defconfig
arm pcm027_defconfig
powerpc tqm8560_defconfig
mips ar7_defconfig
powerpc asp8347_defconfig
sparc64 alldefconfig
mips e55_defconfig
mips vocore2_defconfig
powerpc icon_defconfig
powerpc socrates_defconfig
powerpc tqm5200_defconfig
sh sdk7780_defconfig
m68k atari_defconfig
m68k mvme147_defconfig
arm integrator_defconfig
ia64 tiger_defconfig
m68k bvme6000_defconfig
powerpc tqm8548_defconfig
m68k m5272c3_defconfig
mips ip22_defconfig
powerpc makalu_defconfig
powerpc powernv_defconfig
arm sama5_defconfig
arm spitz_defconfig
powerpc cell_defconfig
nios2 10m50_defconfig
arm h3600_defconfig
powerpc lite5200b_defconfig
h8300 defconfig
arm zeus_defconfig
powerpc mpc837x_mds_defconfig
powerpc ppa8548_defconfig
arm pxa3xx_defconfig
mips rm200_defconfig
arc haps_hs_defconfig
sh se7712_defconfig
arm collie_defconfig
arm gemini_defconfig
arm spear6xx_defconfig
parisc allyesconfig
m68k stmark2_defconfig
sh se7780_defconfig
powerpc adder875_defconfig
mips nlm_xlp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64 randconfig-a014-20210504
x86_64 randconfig-a015-20210504
x86_64 randconfig-a012-20210504
x86_64 randconfig-a013-20210504
x86_64 randconfig-a011-20210504
x86_64 randconfig-a016-20210504
i386 randconfig-a015-20210504
i386 randconfig-a013-20210504
i386 randconfig-a016-20210504
i386 randconfig-a014-20210504
i386 randconfig-a012-20210504
i386 randconfig-a011-20210504
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a001-20210504
x86_64 randconfig-a003-20210504
x86_64 randconfig-a005-20210504
x86_64 randconfig-a002-20210504
x86_64 randconfig-a006-20210504
x86_64 randconfig-a004-20210504
x86_64 randconfig-a014-20210503
x86_64 randconfig-a015-20210503
x86_64 randconfig-a012-20210503
x86_64 randconfig-a011-20210503
x86_64 randconfig-a013-20210503
x86_64 randconfig-a016-20210503
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 7619d98e5041d5c25aba5428704dba6121237a9a
From: kernel test robot @ 2021-05-05 2:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 7619d98e5041d5c25aba5428704dba6121237a9a Automatic merge of 'next' into merge (2021-05-04 11:06)
elapsed time: 723m
configs tested: 151
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
arm mxs_defconfig
mips allyesconfig
mips maltaup_xpa_defconfig
arm viper_defconfig
arm imote2_defconfig
arm imx_v6_v7_defconfig
arm pcm027_defconfig
powerpc tqm8560_defconfig
sh sh7763rdp_defconfig
arm mvebu_v5_defconfig
powerpc storcenter_defconfig
sparc sparc32_defconfig
sh rsk7201_defconfig
mips ar7_defconfig
powerpc asp8347_defconfig
sparc64 alldefconfig
mips e55_defconfig
mips vocore2_defconfig
powerpc icon_defconfig
arm zeus_defconfig
sh landisk_defconfig
powerpc mgcoge_defconfig
arm h3600_defconfig
mips pic32mzda_defconfig
mips xway_defconfig
powerpc socrates_defconfig
powerpc tqm5200_defconfig
sh sdk7780_defconfig
m68k atari_defconfig
m68k mvme147_defconfig
arm integrator_defconfig
ia64 tiger_defconfig
m68k bvme6000_defconfig
powerpc tqm8548_defconfig
m68k m5272c3_defconfig
mips ip22_defconfig
powerpc makalu_defconfig
powerpc adder875_defconfig
powerpc ppc64e_defconfig
riscv nommu_virt_defconfig
arm ixp4xx_defconfig
sh sh7757lcr_defconfig
xtensa cadence_csp_defconfig
powerpc powernv_defconfig
arm sama5_defconfig
arm spitz_defconfig
powerpc cell_defconfig
powerpc mpc837x_mds_defconfig
powerpc ppa8548_defconfig
arm vt8500_v6_v7_defconfig
mips tb0219_defconfig
parisc alldefconfig
nios2 10m50_defconfig
arm spear3xx_defconfig
arm pxa3xx_defconfig
mips rm200_defconfig
arc haps_hs_defconfig
sh se7712_defconfig
arm collie_defconfig
arm gemini_defconfig
arm spear6xx_defconfig
parisc allyesconfig
m68k stmark2_defconfig
sh se7780_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64 randconfig-a014-20210504
x86_64 randconfig-a015-20210504
x86_64 randconfig-a012-20210504
x86_64 randconfig-a013-20210504
x86_64 randconfig-a011-20210504
x86_64 randconfig-a016-20210504
i386 randconfig-a015-20210504
i386 randconfig-a013-20210504
i386 randconfig-a016-20210504
i386 randconfig-a014-20210504
i386 randconfig-a012-20210504
i386 randconfig-a011-20210504
riscv nommu_k210_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a001-20210504
x86_64 randconfig-a003-20210504
x86_64 randconfig-a005-20210504
x86_64 randconfig-a002-20210504
x86_64 randconfig-a006-20210504
x86_64 randconfig-a004-20210504
x86_64 randconfig-a014-20210503
x86_64 randconfig-a015-20210503
x86_64 randconfig-a012-20210503
x86_64 randconfig-a011-20210503
x86_64 randconfig-a013-20210503
x86_64 randconfig-a016-20210503
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes
From: Joel Stanley @ 2021-05-05 1:43 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1620119643.r94ggot8r7.astroid@bobo.none>
On Tue, 4 May 2021 at 09:16, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> > On Mon, 3 May 2021 at 13:04, Nicholas Piggin <npiggin@gmail.com> wrote:
> >>
> >> These aren't necessarily POWER9 only, and it's not to say some new
> >> vulnerability may not get discovered on other processors for which
> >> we would like the flexibility of having the workaround enabled by
> >> firmware.
> >>
> >> Remove the restriction that they only apply to POWER9.
> >
> > I was wondering how these worked which led me to reviewing your patch.
> > From what I could see, these are enabled by default (SEC_FTR_DEFAULT
> > in arch/powerpc/include/asm/security_features.h), so unless all
> > non-POWER9 machines have set the "please don't" bit in their firmware
> > this patch will enable the feature for those machines. Is that what
> > you wanted?
>
> Yes. POWER7/8 should be affected (it's similar mechanism that requires
> the meltdown RFI flush, which those processors need).
>
> POWER10 we haven't released a bare metal firmware with the right bits
> yet. Not urgent at the moment but wouldn't hurt to specify them and
> add the Linux code for them.
Thanks for the explanation. This could go in the commit message if you re-spin.
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox