* Re: [PATCH v3] powerpc/mm: Remove kvm radix prefetch workaround for Power9 DD2.2
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev, kvm-ppc; +Cc: Jordan Niethe, oohall
In-Reply-To: <20191206031722.25781-1-jniethe5@gmail.com>
On Fri, 2019-12-06 at 03:17:22 UTC, Jordan Niethe wrote:
> Commit a25bd72badfa ("powerpc/mm/radix: Workaround prefetch issue with
> KVM") introduced a number of workarounds as coming out of a guest with
> the mmu enabled would make the cpu would start running in hypervisor
> state with the PID value from the guest. The cpu will then start
> prefetching for the hypervisor with that PID value.
>
> In Power9 DD2.2 the cpu behaviour was modified to fix this. When
> accessing Quadrant 0 in hypervisor mode with LPID != 0 prefetching will
> not be performed. This means that we can get rid of the workarounds for
> Power9 DD2.2 and later revisions. Add a new cpu feature
> CPU_FTR_P9_RADIX_PREFETCH_BUG to indicate if the workarounds are needed.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/736bcdd3a9fc672af33fb83230ecd0570ec38ec6
cheers
^ permalink raw reply
* Re: [PATCH v4 1/8] powerpc/32: Add VDSO version of getcpu on non SMP
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel, arnd
In-Reply-To: <eaac4b6494ecff1811220fccc895bf282aab884a.1575273217.git.christophe.leroy@c-s.fr>
On Mon, 2019-12-02 at 07:57:27 UTC, Christophe Leroy wrote:
> Commit 18ad51dd342a ("powerpc: Add VDSO version of getcpu") added
> getcpu() for PPC64 only, by making use of a user readable general
> purpose SPR.
>
> PPC32 doesn't have any such SPR.
>
> For non SMP, just return CPU id 0 from the VDSO directly.
> PPC32 doesn't support CONFIG_NUMA so NUMA node is always 0.
>
> Before the patch, vdsotest reported:
> getcpu: syscall: 1572 nsec/call
> getcpu: libc: 1787 nsec/call
> getcpu: vdso: not tested
>
> Now, vdsotest reports:
> getcpu: syscall: 1582 nsec/call
> getcpu: libc: 502 nsec/call
> getcpu: vdso: 187 nsec/call
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Patches 1, 2 and 4-8, applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/902137ba8e469ed07c7f120a390161937a6288fb
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/devicetrees: Change 'gpios' to 'cs-gpios' on fsl, spi nodes
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Rob Herring, Mark Rutland, Mark Brown
Cc: devicetree, Linus Walleij, linuxppc-dev, linux-kernel, linux-spi
In-Reply-To: <7556683b57d8ce100855857f03d1cd3d2903d045.1574943062.git.christophe.leroy@c-s.fr>
On Thu, 2019-11-28 at 12:16:35 UTC, Christophe Leroy wrote:
> Since commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO
> descriptors"), the prefered way to define chipselect GPIOs is using
> 'cs-gpios' property instead of the legacy 'gpios' property.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8c452a889821ca0cd2a5f2e3e87fbc01e56408cb
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/8xx: Fix permanently mapped IMMR region.
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <45f4f414bcd7198b0755cf4287ff216fbfc24b9d.1574774187.git.christophe.leroy@c-s.fr>
On Tue, 2019-11-26 at 13:16:50 UTC, Christophe Leroy wrote:
> When not using large TLBs, the IMMR region is still
> mapped as a whole block in the FIXMAP area.
>
> Properly report that the IMMR region is block-mapped even
> when not using large TLBs.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/991d656d722dbc783481f408d6e4cbcce2e8bb78
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/hw_breakpoints: Rewrite 8xx breakpoints to allow any address range size.
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
ravi.bangoria
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <05105deeaf63bc02151aea2cdeaf525534e0e9d4.1574790198.git.christophe.leroy@c-s.fr>
On Tue, 2019-11-26 at 17:43:29 UTC, Christophe Leroy wrote:
> Unlike standard powerpc, Powerpc 8xx doesn't have SPRN_DABR, but
> it has a breakpoint support based on a set of comparators which
> allow more flexibility.
>
> Commit 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint")
> implemented breakpoints by emulating the DABR behaviour. It did
> this by setting one comparator the match 4 bytes at breakpoint address
> and the other comparator to match 4 bytes at breakpoint address + 4.
>
> Rewrite 8xx hw_breakpoint to make breakpoints match all addresses
> defined by the breakpoint address and length by making full use of
> comparators.
>
> Now, comparator E is set to match any address greater than breakpoint
> address minus one. Comparator F is set to match any address lower than
> breakpoint address plus breakpoint length. Addresses are aligned
> to 32 bits.
>
> When the breakpoint range starts at address 0, the breakpoint is set
> to match comparator F only. When the breakpoint range end at address
> 0xffffffff, the breakpoint is set to match comparator E only.
> Otherwise the breakpoint is set to match comparator E and F.
>
> At the same time, use registers bit names instead of hardcoded values.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/39413ae009674c6ba745850515b551bbb9d6374b
cheers
^ permalink raw reply
* Re: [PATCH] macintosh: Fix Kconfig indentation
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-kernel; +Cc: linuxppc-dev, Krzysztof Kozlowski
In-Reply-To: <20191120134115.14918-1-krzk@kernel.org>
On Wed, 2019-11-20 at 13:41:15 UTC, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^ /\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/25dd118f4b2773490df12b9d190c1956cf3250c3
cheers
^ permalink raw reply
* Re: [PATCH v2 01/11] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev, andrew.donnellan, clombard
Cc: aik, Frederic Barrat, oohall, groug, alastair
In-Reply-To: <20191121134918.7155-2-fbarrat@linux.ibm.com>
On Thu, 2019-11-21 at 13:49:08 UTC, Frederic Barrat wrote:
> The pci_dn structure used to store a pointer to the struct pci_dev, so
> taking a reference on the device was required. However, the pci_dev
> pointer was later removed from the pci_dn structure, but the reference
> was kept for the npu device.
> See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary
> pcidev from pci_dn").
>
> We don't need to take a reference on the device when assigning the PE
> as the struct pnv_ioda_pe is cleaned up at the same time as
> the (physical) device is released. Doing so prevents the device from
> being released, which is a problem for opencapi devices, since we want
> to be able to remove them through PCI hotplug.
>
> Now the ugly part: nvlink npu devices are not meant to be
> released. Because of the above, we've always leaked a reference and
> simply removing it now is dangerous and would likely require more
> work. There's currently no release device callback for nvlink devices
> for example. So to be safe, this patch leaks a reference on the npu
> device, but only for nvlink and not opencapi.
>
> CC: aik@ozlabs.ru
> CC: oohall@gmail.com
> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/05dd7da76986937fb288b4213b1fa10dbe0d1b33
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Drop extern qualifiers from header function prototypes
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Greg Kurz; +Cc: linuxppc-dev, trivial, Cédric Le Goater
In-Reply-To: <157384145834.181768.944827793193636924.stgit@bahia.lan>
On Fri, 2019-11-15 at 18:10:58 UTC, Greg Kurz wrote:
> As reported by ./scripts/checkpatch.pl --strict:
>
> CHECK: extern prototypes should be avoided in .h files
>
> Signed-off-by: Greg Kurz <groug@kaod.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b059c63620fbba8a5da60f01d99d003681447e3c
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/powernv: Rework exports to support subnodes
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20191101062611.32610-1-oohall@gmail.com>
On Fri, 2019-11-01 at 06:26:10 UTC, Oliver O'Halloran wrote:
> Originally we only had a handful of exported memory ranges, but we'd to
> export the per-core trace buffers. This results in a lot of files in the
> exports directory which is a but unfortunate. We can clean things up a bit
> by turning subnodes into subdirectories of the exports directory.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/db93361260e2411f854514e8b54b6c31a5b2d5bd
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/xmon: Allow passing an argument to ppc_md.restart()
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20191101085522.3055-1-oohall@gmail.com>
On Fri, 2019-11-01 at 08:55:21 UTC, Oliver O'Halloran wrote:
> On PowerNV a few different kinds of reboot are supported. We'd like to be
> able to exercise these from xmon so allow 'zr' to take an argument, and
> pass that to the ppc_md.restart() function.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2d9b332d99b24f27f77e9ba38ce3c8beb11a81c0
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powernv/pci: Use pnv_phb as the private data for debugfs entries
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20190912052945.12589-1-oohall@gmail.com>
On Thu, 2019-09-12 at 05:29:43 UTC, Oliver O'Halloran wrote:
> Use the pnv_phb structure as the private data pointer for the debugfs
> files. This lets us delete some code and an open-coded use of
> hose->private_data.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/22ba7289079be12c85895fee41602139e9553c93
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: Only dump stack once if an MMIO loop is detected
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Sam Bobroff, Oliver O'Halloran
In-Reply-To: <20191016012536.22588-1-oohall@gmail.com>
On Wed, 2019-10-16 at 01:25:36 UTC, Oliver O'Halloran wrote:
> Many drivers don't check for errors when they get a 0xFFs response from an
> MMIO load. As a result after an EEH event occurs a driver can get stuck in
> a polling loop unless it some kind of internal timeout logic.
>
> Currently EEH tries to detect and report stuck drivers by dumping a stack
> trace after eeh_dev_check_failure() is called EEH_MAX_FAILS times on an
> already frozen PE. The value of EEH_MAX_FAILS was chosen so that a dump
> would occur every few seconds if the driver was spinning in a loop. This
> results in a lot of spurious stack traces in the kernel log.
>
> Fix this by limiting it to printing one stack trace for each PE freeze. If
> the driver is truely stuck the kernel's hung task detector is better suited
> to reporting the probelm anyway.
>
> Cc: Sam Bobroff <sbobroff@linux.ibm.com>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4e0942c0302b5ad76b228b1a7b8c09f658a1d58a
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: sbobroff, Oliver O'Halloran
In-Reply-To: <20190821062655.19735-1-oohall@gmail.com>
On Wed, 2019-08-21 at 06:26:53 UTC, Oliver O'Halloran wrote:
> When disabling virtual functions on an SR-IOV adapter we currently do not
> correctly remove the EEH state for the now-dead virtual functions. When
> removing the pci_dn that was created for the VF when SR-IOV was enabled
> we free the corresponding eeh_dev without removing it from the child device
> list of the eeh_pe that contained it. This can result in crashes due to the
> use-after-free.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1fb4124ca9d456656a324f1ee29b7bf942f59ac8
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: remplement power4_idle code in C
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190711022404.18132-1-npiggin@gmail.com>
On Thu, 2019-07-11 at 02:24:03 UTC, Nicholas Piggin wrote:
> This implements the tricky tracing and soft irq handling bits in C,
> leaving the low level bit to asm.
>
> A functional difference is that this redirects the interrupt exit to
> a return stub to execute blr, rather than the lr address itself. This
> is probably barely measurable on real hardware, but it keeps the link
> stack balanced.
>
> Tested with QEMU.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ed0bc98f8cbe4f8254759d333a47aedc816ff8c5
cheers
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/eeh_cache: Don't use pci_dn when inserting new ranges
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: sbobroff, Oliver O'Halloran
In-Reply-To: <20190715085612.8802-2-oohall@gmail.com>
On Mon, 2019-07-15 at 08:56:08 UTC, Oliver O'Halloran wrote:
> At the point where we start inserting ranges into the EEH address cache the
> binding between pci_dev and eeh_dev has already been set up. Instead of
> consulting the pci_dn tree we can retrieve the eeh_dev directly using
> pci_dev_to_eeh_dev().
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b1268f4cdba71c0cd40b533778812340d36de8ae
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: XIVE: Fix typo in comment
From: Michael Ellerman @ 2020-01-29 5:17 UTC (permalink / raw)
To: Greg Kurz; +Cc: linuxppc-dev, trivial, linux-kernel
In-Reply-To: <156219139988.578018.1046848908285019838.stgit@bahia.lan>
On Wed, 2019-07-03 at 22:03:19 UTC, Greg Kurz wrote:
> Cc: trivial@kernel.org
> Signed-off-by: Greg Kurz <groug@kaod.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6a3163212f311daaf2ca3b676db2e11cfd81c6b3
cheers
^ permalink raw reply
* Re: powerpc Linux scv support and scv system call ABI proposal
From: Nicholas Piggin @ 2020-01-29 4:58 UTC (permalink / raw)
To: Adhemerval Zanella, linuxppc-dev
In-Reply-To: <cd9e4b28-d577-8850-7c2b-a488fcb4740d@linaro.org>
Adhemerval Zanella's on January 29, 2020 3:26 am:
>
>
> On 28/01/2020 11:05, Nicholas Piggin wrote:
>> Florian Weimer's on January 28, 2020 11:09 pm:
>>> * Nicholas Piggin:
>>>
>>>> * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other
>>>> vectors will return -ENOSYS, and the decision for how to add support for
>>>> a new vector deferred until we see the next user.
>>>
>>> Seems reasonable. We don't have to decide this today.
>>>
>>>> * Proposal is for scv 0 to provide the standard Linux system call ABI with some
>>>> differences:
>>>>
>>>> - LR is volatile across scv calls. This is necessary for support because the
>>>> scv instruction clobbers LR.
>>>
>>> I think we can express this in the glibc system call assembler wrapper
>>> generators. The mcount profiling wrappers already have this property.
>>>
>>> But I don't think we are so lucky for the inline system calls. GCC
>>> recognizes an "lr" clobber with inline asm (even though it is not
>>> documented), but it generates rather strange assembler output as a
>>> result:
>>>
>>> long
>>> f (long x)
>>> {
>>> long y;
>>> asm ("#" : "=r" (y) : "r" (x) : "lr");
>>> return y;
>>> }
>>>
>>> .abiversion 2
>>> .section ".text"
>>> .align 2
>>> .p2align 4,,15
>>> .globl f
>>> .type f, @function
>>> f:
>>> .LFB0:
>>> .cfi_startproc
>>> mflr 0
>>> .cfi_register 65, 0
>>> #APP
>>> # 5 "t.c" 1
>>> #
>>> # 0 "" 2
>>> #NO_APP
>>> std 0,16(1)
>>> .cfi_offset 65, 16
>>> ori 2,2,0
>>> ld 0,16(1)
>>> mtlr 0
>>> .cfi_restore 65
>>> blr
>>> .long 0
>>> .byte 0,0,0,1,0,0,0,0
>>> .cfi_endproc
>>> .LFE0:
>>> .size f,.-f
>>>
>>>
>>> That's with GCC 8.3 at -O2. I don't understand what the ori is about.
>>
>> ori 2,2,0 is the group terminating nop hint for POWER8 type cores
>> which had dispatch grouping rules.
>
> It worth to note that it aims to mitigate a load-hit-store cpu stall
> on some powerpc chips.
>
>>
>>>
>>> I don't think we can save LR in a regular register around the system
>>> call, explicitly in the inline asm statement, because we still have to
>>> generate proper unwinding information using CFI directives, something
>>> that you cannot do from within the asm statement.
>>>
>>> Supporting this in GCC should not be impossible, but someone who
>>> actually knows this stuff needs to look at it.
>>
>> The generated assembler actually seems okay to me. If we compile
>> something like a syscall and with -mcpu=power9:
>>
>> long
>> f (long _r3, long _r4, long _r5, long _r6, long _r7, long _r8, long _r0)
>> {
>> register long r0 asm ("r0") = _r0;
>> register long r3 asm ("r3") = _r3;
>> register long r4 asm ("r4") = _r4;
>> register long r5 asm ("r5") = _r5;
>> register long r6 asm ("r6") = _r6;
>> register long r7 asm ("r7") = _r7;
>> register long r8 asm ("r8") = _r8;
>>
>> asm ("# scv" : "=r"(r3) : "r"(r0), "r"(r4), "r"(r5), "r"(r6), "r"(r7), "r"(r8) : "lr", "ctr", "cc", "xer");
>>
>> return r3;
>> }
>>
>>
>> f:
>> .LFB0:
>> .cfi_startproc
>> mflr 0
>> std 0,16(1)
>> .cfi_offset 65, 16
>> mr 0,9
>> #APP
>> # 12 "a.c" 1
>> # scv
>> # 0 "" 2
>> #NO_APP
>> ld 0,16(1)
>> mtlr 0
>> .cfi_restore 65
>> blr
>> .long 0
>> .byte 0,0,0,1,0,0,0,0
>> .cfi_endproc
>>
>> That gets the LR save/restore right when we're also using r0.
>>
>>>
>>>> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
>>>> system call exit to avoid restoring the CR register.
>>>
>>> This sounds reasonable, but I don't know what kind of knock-on effects
>>> this has. The inline system call wrappers can handle this with minor
>>> tweaks.
>>
>> Okay, good. In the end we would have to check code trace through the
>> kernel and libc of course, but I think there's little to no opportunity
>> to take advantage of current extra non-volatile cr regs.
>>
>> mtcr has to write 8 independently renamed registers so it's cracked into
>> 2 insns on POWER9 (and likely to always be a bit troublesome). It's not
>> much in the scheme of a system call, but while we can tweak the ABI...
>
> We don't really need a mfcr/mfocr to implement the Linux syscall ABI on
> powerpc, we can use a 'bns+' plus a neg instead as:
>
> --
> #define internal_syscall6(name, err, nr, arg1, arg2, arg3, arg4, arg5, \
> arg6) \
> ({ \
> register long int r0 __asm__ ("r0") = (long int) (name); \
> register long int r3 __asm__ ("r3") = (long int) (arg1); \
> register long int r4 __asm__ ("r4") = (long int) (arg2); \
> register long int r5 __asm__ ("r5") = (long int) (arg3); \
> register long int r6 __asm__ ("r6") = (long int) (arg4); \
> register long int r7 __asm__ ("r7") = (long int) (arg5); \
> register long int r8 __asm__ ("r8") = (long int) (arg6); \
> __asm__ __volatile__ \
> ("sc\n\t" \
> "bns+ 1f\n\t" \
> "neg %1, %1\n\t" \
> "1:\n\t" \
> : "+r" (r0), "+r" (r3), "+r" (r4), "+r" (r5), "+r" (r6), \
> "+r" (r7), "+r" (r8) \
> : \
> : "r9", "r10", "r11", "r12", \
> "cr0", "memory"); \
> r3; \
> })
True, but the taken branch would be a 1 cycle bubble in fetch. Could
avoid that by branching out of line then back for the error case. But
mfocrf is fine (only sources one register), that's what should be used
here I think.
That probably makes the performance argument for avoiding CR[SO] for
error return indication less significant. Commonality with other
architectures is probably the bigger reason for it.
> --
>
> And change INTERNAL_SYSCALL_ERROR_P to check for the expected invalid
> range (((unsigned long) (val) >= (unsigned long) -4095)) and
> INTERNAL_SYSCALL_ERRNO to return a negative value (since the value will
> be negated by INTERNAL_SYSCALL_ERROR_P).
>
> The powerpc kernel ABI to use a different constraint to signal error
> also requires glibc to reimplement the vDSO symbol call to be arch
> specific instead a straight function call (since it might fallbacks
> to a syscall).
>
> Even for POWER-specific system call that uses all result bits, either
> it should not fail or it would require a arch-specific implementation
> to setup the expected error value (since the information would require
> another source or a pre-defined value).
>
> In fact I think we make the assumption that INTERNAL_SYSCALL returns
> a negative errno value in case or an error and make all the handling
> to check for a syscall failure and errno setting generic. This will
> required change ia64, mips, nios2, and sparc though.
>
>>
>>>
>>>> - Error handling: use of CR0[SO] to indicate error requires a mtcr / mtocr
>>>> instruction on the kernel side, and it is currently not implemented well
>>>> in glibc, requiring a mfcr (mfocr should be possible and asm goto support
>>>> would allow a better implementation). Is it worth continuing this style of
>>>> error handling? Or just move to -ve return means error? Using a different
>>>> bit would allow the kernel to piggy back the CR return code setting with
>>>> a test for the error case exit.
>>>
>>> GCC does not model the condition registers, so for inline system calls,
>>> we have to produce a value anyway that the subsequence C code can check.
>>> The assembler syscall wrappers do not need to do this, of course, but
>>> I'm not sure which category of interfaces is more important.
>>
>> Right. asm goto can improve this kind of pattern if it's inlined
>> into the C code which tests the result, it can branch using the flags
>> to the C error handling label, rather than move flags into GPR, test
>> GPR, branch. However...
>>
>>> But the kernel uses the -errno convention internally, so I think it
>>> would make sense to pass this to userspace and not convert back and
>>> forth. This would align with what most of the architectures do, and
>>> also avoids the GCC oddity.
>>
>> Yes I would be interested in opinions for this option. It seems like
>> matching other architectures is a good idea. Maybe there are some
>> reasons not to.
>>
>>>> - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit
>>>> calls if there was interest in developing an ABI for 32-bit programs.
>>>> Marginal benefit in avoiding compat syscall selection.
>>>
>>> We don't have an ELFv2 ABI for 32-bit. I doubt it makes sense to
>>> provide an ELFv1 port for this given that it's POWER9-specific.
>>
>> Okay. There's no reason not to enable this for BE, at least for the
>> kernel it's no additional work so it probably remains enabled (unless
>> there is something really good we could do with the ABI if we exclude
>> ELFv1 but I don't see anything).
>>
>> But if glibc only builds for ELFv2 support that's probably reasonable.
>>
>>>
>>> From the glibc perspective, the major question is how we handle run-time
>>> selection of the system call instruction sequence. On i386, we use a
>>> function pointer in the TCB to call an instruction sequence in the vDSO.
>>> That's problematic from a security perspective. I expect that on
>>> POWER9, using a pointer in read-only memory would be equally
>>> non-attractive due to a similar lack of PC-relative addressing. We
>>> could use the HWCAP bit in the TCB, but that would add another (easy to
>>> predict) conditional branch to every system call.
>>
>> I would have to defer to glibc devs on this. Conditional branch
>> should be acceptable I think, scv improves speed as much as several
>> mispredicted branches (about 90 cycles).
>>
>>> I don't think it matters whether both system call variants use the same
>>> error convention because we could have different error code extraction
>>> code on the two branches.
>>
>> That's one less difficulty.
>
> We already had to push a similar hack where glibc used to abort transactions
> prior syscalls to avoid some side-effects on kernel (commit 56cf2763819d2f).
> It was eventually removed from syscall handling by f0458cf4f9ff3d870, where
> we only enable TLE if kernel suppors PPC_FEATURE2_HTM_NOSC.
>
> The transaction syscall abort used to read a variable directly from TCB,
> so this could be an option. I would expect that we could optimize it where
> if glibc is building against a recent kernel and compiler is building
> for a ISA 3.0+ cpu we could remove the 'sc' code.
>
We would just have to be careful of running on ISA 3.0 CPUs on older
kernels which do not support scv.
I don't think this is such a big deal, yes we'll have a switch for a
time and it will be slightly slower, but we can eventually remove it.
Thanks,
Nick
^ permalink raw reply
* Re: powerpc Linux scv support and scv system call ABI proposal
From: Nicholas Piggin @ 2020-01-29 4:41 UTC (permalink / raw)
To: Florian Weimer; +Cc: linuxppc-dev, Tulio Magno Quites Machado Filho, libc-alpha
In-Reply-To: <87sgjzbmk1.fsf@oldenburg2.str.redhat.com>
Florian Weimer's on January 29, 2020 1:58 am:
> * Nicholas Piggin:
>
>> That gets the LR save/restore right when we're also using r0.
>
> Yes, I agree it looks good. Nice.
>
>>> But the kernel uses the -errno convention internally, so I think it
>>> would make sense to pass this to userspace and not convert back and
>>> forth. This would align with what most of the architectures do, and
>>> also avoids the GCC oddity.
>>
>> Yes I would be interested in opinions for this option. It seems like
>> matching other architectures is a good idea. Maybe there are some
>> reasons not to.
>
> If there were a POWER-specific system call that uses all result bits and
> doesn't have room for the 4096 error states (or an error number that's
> outside that range), that would be a blocker. I can't find such a
> system call wrapped in the glibc sources.
Nothing apparent in the kernel sources either.
> musl's inline syscalls always
> convert the errno state to -errno, so it's not possible to use such a
> system call there.
>
>>>> - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit
>>>> calls if there was interest in developing an ABI for 32-bit programs.
>>>> Marginal benefit in avoiding compat syscall selection.
>>>
>>> We don't have an ELFv2 ABI for 32-bit. I doubt it makes sense to
>>> provide an ELFv1 port for this given that it's POWER9-specific.
>>
>> Okay. There's no reason not to enable this for BE, at least for the
>> kernel it's no additional work so it probably remains enabled (unless
>> there is something really good we could do with the ABI if we exclude
>> ELFv1 but I don't see anything).
>>
>> But if glibc only builds for ELFv2 support that's probably reasonable.
>
> To be clear, we still support ELFv1 for POWER, but given that this
> feature is POWER9 and later, I expect the number of users benefiting
> from 32-bit support (or ELFv1 and thus big-endian support) to be quite
> small.
>
> Especially if we go the conditional branch route, I would restrict this
> to ELFv2 in glibc, at least for default builds.
>
>>> From the glibc perspective, the major question is how we handle run-time
>>> selection of the system call instruction sequence. On i386, we use a
>>> function pointer in the TCB to call an instruction sequence in the vDSO.
>>> That's problematic from a security perspective. I expect that on
>>> POWER9, using a pointer in read-only memory would be equally
>>> non-attractive due to a similar lack of PC-relative addressing. We
>>> could use the HWCAP bit in the TCB, but that would add another (easy to
>>> predict) conditional branch to every system call.
>>
>> I would have to defer to glibc devs on this. Conditional branch
>> should be acceptable I think, scv improves speed as much as several
>> mispredicted branches (about 90 cycles).
>
> But we'd have to pay for that branch (and likely the LR clobber) on
> legacy POWER, and that's something to consider, too.
We would that's true.
> Is there an additional performance hit if a process uses both the old
> and new system call sequence?
No state or logic required to switch between them or run them
concurrently. Just the extra instruction footprint.
Thanks,
Nick
^ permalink raw reply
* [PATCH RESEND] powerpc: indent to improve Kconfig readability
From: Randy Dunlap @ 2020-01-29 2:22 UTC (permalink / raw)
To: PowerPC; +Cc: Paul Mackerras
From: Randy Dunlap <rdunlap@infradead.org>
Indent a Kconfig continuation line to improve readability.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200128.orig/arch/powerpc/Kconfig
+++ linux-next-20200128/arch/powerpc/Kconfig
@@ -478,7 +478,7 @@ config MPROFILE_KERNEL
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
- PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
+ PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
help
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
^ permalink raw reply
* Re: [PATCH v2 07/10] powerpc/configs/skiroot: Enable security features
From: Daniel Axtens @ 2020-01-29 1:29 UTC (permalink / raw)
To: Joel Stanley, Michael Ellerman; +Cc: linuxppc-dev, Oliver O'Halloran
In-Reply-To: <CACPK8XeXNb_9ftjtTKG2i6DbyFwWFAT4bPhQ0+6eR8i-1a5JrQ@mail.gmail.com>
Joel Stanley <joel@jms.id.au> writes:
> On Tue, 21 Jan 2020 at 04:30, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> From: Joel Stanley <joel@jms.id.au>
>>
>> This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and
>> FORTIFY_SOURCE.
>>
>> It also enables SECURITY_LOCKDOWN_LSM with _EARLY and
>> LOCK_DOWN_KERNEL_FORCE_INTEGRITY options enabled. This still allows
>> xmon to be used in read-only mode.
>>
>> MODULE_SIG is selected by lockdown, so it is still enabled.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [mpe: Switch to lockdown integrity mode per oohal]
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> I did some testing and with change we break kexec. As it's critical
> for this kernel to be able to kexec we need to set KEXEC_FILE=y if
> we're setting FORCE_INTEGRITY=y.
>
> I've tested your series with that modification made and userspace was
> once again able to kexec (with -s).
Has the changes that enable this landed in kexec-lite and petitboot yet?
I had to manually patch them when I was experimenting with it
recently...
Regards,
Daniel
>
> Cheers,
>
> Joel
>
>> ---
>> arch/powerpc/configs/skiroot_defconfig | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> v2: Switch to lockdown integrity mode rather than confidentiality as noticed by
>> dja and discussed with jms and oohal.
>>
>> diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
>> index 24a210fe0049..93b478436a2b 100644
>> --- a/arch/powerpc/configs/skiroot_defconfig
>> +++ b/arch/powerpc/configs/skiroot_defconfig
>> @@ -49,7 +49,6 @@ CONFIG_JUMP_LABEL=y
>> CONFIG_STRICT_KERNEL_RWX=y
>> CONFIG_MODULES=y
>> CONFIG_MODULE_UNLOAD=y
>> -CONFIG_MODULE_SIG=y
>> CONFIG_MODULE_SIG_FORCE=y
>> CONFIG_MODULE_SIG_SHA512=y
>> CONFIG_PARTITION_ADVANCED=y
>> @@ -272,6 +271,16 @@ CONFIG_NLS_ASCII=y
>> CONFIG_NLS_ISO8859_1=y
>> CONFIG_NLS_UTF8=y
>> CONFIG_ENCRYPTED_KEYS=y
>> +CONFIG_SECURITY=y
>> +CONFIG_HARDENED_USERCOPY=y
>> +# CONFIG_HARDENED_USERCOPY_FALLBACK is not set
>> +CONFIG_HARDENED_USERCOPY_PAGESPAN=y
>> +CONFIG_FORTIFY_SOURCE=y
>> +CONFIG_SECURITY_LOCKDOWN_LSM=y
>> +CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
>> +CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY=y
>> +# CONFIG_INTEGRITY is not set
>> +CONFIG_LSM="yama,loadpin,safesetid,integrity"
>> # CONFIG_CRYPTO_HW is not set
>> CONFIG_CRC16=y
>> CONFIG_CRC_ITU_T=y
>> --
>> 2.21.1
>>
^ permalink raw reply
* Re: [PATCH] powerpc/drmem: cache LMBs in xarray to accelerate lookup
From: Nathan Lynch @ 2020-01-28 23:56 UTC (permalink / raw)
To: Scott Cheloha; +Cc: Nathan Fontenont, linuxppc-dev, linux-kernel, Rick Lindsley
In-Reply-To: <20200128221113.17158-1-cheloha@linux.ibm.com>
Scott Cheloha <cheloha@linux.ibm.com> writes:
> LMB lookup is currently an O(n) linear search. This scales poorly when
> there are many LMBs.
>
> If we cache each LMB by both its base address and its DRC index
> in an xarray we can cut lookups to O(log n), greatly accelerating
> drmem initialization and memory hotplug.
>
> This patch introduces two xarrays of of LMBs and fills them during
> drmem initialization. The patch also adds two interfaces for LMB
> lookup.
Good but can you replace the array of LMBs altogether
(drmem_info->lmbs)? xarray allows iteration over the members if needed.
^ permalink raw reply
* [PATCH] powerpc/drmem: cache LMBs in xarray to accelerate lookup
From: Scott Cheloha @ 2020-01-28 22:11 UTC (permalink / raw)
To: linux-kernel, Michael Ellerman
Cc: Nathan Lynch, Nathan Fontenont, linuxppc-dev, Rick Lindley
LMB lookup is currently an O(n) linear search. This scales poorly when
there are many LMBs.
If we cache each LMB by both its base address and its DRC index
in an xarray we can cut lookups to O(log n), greatly accelerating
drmem initialization and memory hotplug.
This patch introduces two xarrays of of LMBs and fills them during
drmem initialization. The patch also adds two interfaces for LMB
lookup.
The first interface, drmem_find_lmb_by_base_addr(), is employed in
hot_add_drconf_scn_to_nid() to replace a linear search. This speeds up
memory_add_physaddr_to_nid(), which is called by lmb_set_nid(), an
interface used during drmem initialization and memory hotplug.
The second interface, drmem_find_lmb_by_drc_index(), is employed in
get_lmb_range() to replace a linear search. This speeds up
dlpar_memory_add_by_ic() and dlpar_memory_remove_by_ic(), interfaces
used during memory hotplug.
These substitutions yield significant improvements:
1. A POWER9 VM with a maximum memory of 10TB and 256MB LMBs has
40960 LMBs. With this patch it completes drmem_init() ~1138ms
faster.
Before:
[ 0.542244] drmem: initializing drmem v1
[ 1.768787] drmem: initialized 40960 LMBs
After:
[ 0.543611] drmem: initializing drmem v1
[ 0.631386] drmem: initialized 40960 LMBs
2. A POWER9 VM with a maximum memory of 4TB and 256MB LMBs has
16384 LMBs. Via the qemu monitor we can hot-add memory as
virtual DIMMs. Each DIMM is 256 LMBs. With this patch we
hot-add every possible LMB about 60 seconds faster.
Before:
[ 17.422177] pseries-hotplug-mem: Attempting to hot-add 256 LMB(s) at index 80000100
[...]
[ 167.285563] pseries-hotplug-mem: Memory at 3fff0000000 (drc index 80003fff) was hot-added
After:
[ 14.753480] pseries-hotplug-mem: Attempting to hot-add 256 LMB(s) at index 80000100
[...]
[ 103.934092] pseries-hotplug-mem: Memory at 3fff0000000 (drc index 80003fff) was hot-added
Signed-off-by: Scott Cheloha <cheloha@linux.ibm.com>
---
These linear searches become a serious bottleneck as the machine
approaches 64TB. There are just too many LMBs to use a linear
search.
On a 60TB machine we recently saw the following soft lockup during
drmem_init():
[ 60.602386] watchdog: BUG: soft lockup - CPU#9 stuck for 23s! [swapper/0:1]
[ 60.602414] Modules linked in:
[ 60.602417] Supported: No, Unreleased kernel
[ 60.602423] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.3.18-2-default #1 SLE15-SP2 (unreleased)
[ 60.602426] NIP: c000000000095c0c LR: c000000000095bb0 CTR: 0000000000000000
[ 60.602430] REGS: c00022c7fc497830 TRAP: 0901 Not tainted (5.3.18-2-default)
[ 60.602432] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 44000244 XER: 00000000
[ 60.602442] CFAR: c000000000095c18 IRQMASK: 0
GPR00: c000000000095bb0 c00022c7fc497ac0 c00000000162cc00 c0003bffffff5e08
GPR04: 0000000000000000 c000000000ea539a 000000000000002f 0000000010000000
GPR08: c00007fc5f59ffb8 000014bc50000000 c00007fc5f1f1a30 c0000000014f2fb8
GPR12: 0000000000000000 c00000001e980600
[ 60.602464] NIP [c000000000095c0c] hot_add_scn_to_nid+0xbc/0x400
[ 60.602467] LR [c000000000095bb0] hot_add_scn_to_nid+0x60/0x400
[ 60.602470] Call Trace:
[ 60.602473] [c00022c7fc497ac0] [c000000000095bb0] hot_add_scn_to_nid+0x60/0x400 (unreliable)
[ 60.602478] [c00022c7fc497b20] [c00000000007a6a0] memory_add_physaddr_to_nid+0x20/0x60
[ 60.602483] [c00022c7fc497b40] [c0000000010235a4] drmem_init+0x258/0x2d8
[ 60.602485] [c00022c7fc497c10] [c000000000010694] do_one_initcall+0x64/0x300
[ 60.602489] [c00022c7fc497ce0] [c0000000010144f8] kernel_init_freeable+0x2e8/0x3fc
[ 60.602491] [c00022c7fc497db0] [c000000000010b0c] kernel_init+0x2c/0x160
[ 60.602497] [c00022c7fc497e20] [c00000000000b960] ret_from_kernel_thread+0x5c/0x7c
[ 60.602498] Instruction dump:
[ 60.602501] 7d0a4214 7faa4040 419d0328 e92a0010 71290088 2fa90008 409e001c e92a0000
[ 60.602506] 7fbe4840 419c0010 7d274a14 7fbe4840 <419c00e4> 394a0018 7faa4040 409dffd0
This patch should eliminate the drmem_init() bottleneck during boot.
One other important thing to note is that this only addresses part of
the slowdown during memory hotplug when there are many LMBs. A far larger
part of it is caused by the linear memblock search in find_memory_block().
That problem is addressed with this patch:
https://lore.kernel.org/lkml/20200121231028.13699-1-cheloha@linux.ibm.com/
which is in linux-next. The numbers I quote here in the commit message
for time improvements during hotplug are taken with that patch applied.
Without it, hotplug is even slower.
arch/powerpc/include/asm/drmem.h | 3 ++
arch/powerpc/mm/drmem.c | 33 +++++++++++++++++++
arch/powerpc/mm/numa.c | 30 +++++++----------
.../platforms/pseries/hotplug-memory.c | 11 ++-----
4 files changed, 50 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index 3d76e1c388c2..a37cbe794cdd 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -88,6 +88,9 @@ static inline bool drmem_lmb_reserved(struct drmem_lmb *lmb)
return lmb->flags & DRMEM_LMB_RESERVED;
}
+struct drmem_lmb *drmem_find_lmb_by_base_addr(unsigned long);
+struct drmem_lmb *drmem_find_lmb_by_drc_index(unsigned long);
+
u64 drmem_lmb_memory_max(void);
void __init walk_drmem_lmbs(struct device_node *dn,
void (*func)(struct drmem_lmb *, const __be32 **));
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 557d9080604d..7c464b0a256e 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -11,9 +11,12 @@
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/memblock.h>
+#include <linux/xarray.h>
#include <asm/prom.h>
#include <asm/drmem.h>
+static DEFINE_XARRAY(drmem_lmb_base_addr);
+static DEFINE_XARRAY(drmem_lmb_drc_index);
static struct drmem_lmb_info __drmem_info;
struct drmem_lmb_info *drmem_info = &__drmem_info;
@@ -25,6 +28,31 @@ u64 drmem_lmb_memory_max(void)
return last_lmb->base_addr + drmem_lmb_size();
}
+struct drmem_lmb *drmem_find_lmb_by_base_addr(unsigned long base_addr)
+{
+ return xa_load(&drmem_lmb_base_addr, base_addr);
+}
+
+struct drmem_lmb *drmem_find_lmb_by_drc_index(unsigned long drc_index)
+{
+ return xa_load(&drmem_lmb_drc_index, drc_index);
+}
+
+static int drmem_lmb_cache_for_lookup(struct drmem_lmb *lmb)
+{
+ void *ret;
+
+ ret = xa_store(&drmem_lmb_base_addr, lmb->base_addr, lmb, GFP_KERNEL);
+ if (xa_err(ret))
+ return xa_err(ret);
+
+ ret = xa_store(&drmem_lmb_drc_index, lmb->drc_index, lmb, GFP_KERNEL);
+ if (xa_err(ret))
+ return xa_err(ret);
+
+ return 0;
+}
+
static u32 drmem_lmb_flags(struct drmem_lmb *lmb)
{
/*
@@ -364,6 +392,8 @@ static void __init init_drmem_v1_lmbs(const __be32 *prop)
for_each_drmem_lmb(lmb) {
read_drconf_v1_cell(lmb, &prop);
+ if (drmem_lmb_cache_for_lookup(lmb) != 0)
+ return;
lmb_set_nid(lmb);
}
}
@@ -411,6 +441,9 @@ static void __init init_drmem_v2_lmbs(const __be32 *prop)
lmb->aa_index = dr_cell.aa_index;
lmb->flags = dr_cell.flags;
+ if (drmem_lmb_cache_for_lookup(lmb) != 0)
+ return;
+
lmb_set_nid(lmb);
}
}
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 50d68d21ddcc..23684d44549f 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -958,27 +958,21 @@ early_param("topology_updates", early_topology_updates);
static int hot_add_drconf_scn_to_nid(unsigned long scn_addr)
{
struct drmem_lmb *lmb;
- unsigned long lmb_size;
- int nid = NUMA_NO_NODE;
-
- lmb_size = drmem_lmb_size();
-
- for_each_drmem_lmb(lmb) {
- /* skip this block if it is reserved or not assigned to
- * this partition */
- if ((lmb->flags & DRCONF_MEM_RESERVED)
- || !(lmb->flags & DRCONF_MEM_ASSIGNED))
- continue;
- if ((scn_addr < lmb->base_addr)
- || (scn_addr >= (lmb->base_addr + lmb_size)))
- continue;
+ lmb = drmem_find_lmb_by_base_addr(scn_addr);
+ if (lmb == NULL)
+ return NUMA_NO_NODE;
- nid = of_drconf_to_nid_single(lmb);
- break;
- }
+ /*
+ * We can't use it if it is reserved or not assigned to
+ * this partition.
+ */
+ if (lmb->flags & DRCONF_MEM_RESERVED)
+ return NUMA_NO_NODE;
+ if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
+ return NUMA_NO_NODE;
- return nid;
+ return of_drconf_to_nid_single(lmb);
}
/*
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index c126b94d1943..29bd19831a9a 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -222,17 +222,10 @@ static int get_lmb_range(u32 drc_index, int n_lmbs,
struct drmem_lmb **start_lmb,
struct drmem_lmb **end_lmb)
{
- struct drmem_lmb *lmb, *start, *end;
+ struct drmem_lmb *start, *end;
struct drmem_lmb *last_lmb;
- start = NULL;
- for_each_drmem_lmb(lmb) {
- if (lmb->drc_index == drc_index) {
- start = lmb;
- break;
- }
- }
-
+ start = drmem_find_lmb_by_drc_index(drc_index);
if (!start)
return -EINVAL;
--
2.24.1
^ permalink raw reply related
* Re: powerpc Linux scv support and scv system call ABI proposal
From: Joseph Myers @ 2020-01-28 22:14 UTC (permalink / raw)
To: Florian Weimer
Cc: libc-alpha, Tulio Magno Quites Machado Filho, linuxppc-dev,
Nicholas Piggin
In-Reply-To: <87tv4fd8wp.fsf@oldenburg2.str.redhat.com>
On Tue, 28 Jan 2020, Florian Weimer wrote:
> I don't think we can save LR in a regular register around the system
> call, explicitly in the inline asm statement, because we still have to
> generate proper unwinding information using CFI directives, something
> that you cannot do from within the asm statement.
What other architectures in glibc have done for code sequences for
syscalls that are problematic for compiler-generated CFI is made the C
syscall macros call separate functions defined in a .S file (see
sysdeps/unix/sysv/linux/arm/libc-do-syscall.S,
sysdeps/unix/sysv/linux/i386/libc-do-syscall.S,
sysdeps/unix/sysv/linux/mips/mips32/mips-syscall[567].S). I don't know if
you can do that in this case and still get the performance benefits of the
new instruction.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: [PATCH v6 03/10] perf/core: open access to probes for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:16 UTC (permalink / raw)
To: Alexey Budankov
Cc: Song Liu, Peter Zijlstra, Alexei Starovoitov, Lionel Landwerlin,
james.bottomley@hansenpartnership.com, Paul Mackerras, Jiri Olsa,
Andi Kleen, Igor Lubashev, Alexander Shishkin, Ingo Molnar,
oprofile-list, Serge Hallyn, Robert Richter, Will Deacon,
selinux@vger.kernel.org, intel-gfx@lists.freedesktop.org,
Arnaldo Carvalho de Melo, Stephane Eranian, Namhyung Kim,
linux-arm-kernel, linux-parisc@vger.kernel.org, linux-kernel,
linux-perf-users@vger.kernel.org,
linux-security-module@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6cdc10f2-31e5-6d71-7d71-c6b5250b74f1@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
> chances to misuse the credentials and makes operation more secure.
>
> perf kprobes and uprobes are used by ftrace and eBPF. perf probe uses
> ftrace to define new kprobe events, and those events are treated as
> tracepoint events. eBPF defines new probes via perf_event_open interface
> and then the probes are used in eBPF tracing.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39 principle
> of least privilege: A security design principle that states that a process or
> program be granted only those privileges (e.g., capabilities) necessary to
> accomplish its legitimate function, and only for the time that such privileges
> are actually required)
>
> For backward compatibility reasons access to perf_events subsystem remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
> secure perf_events monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> kernel/events/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v6 07/10] powerpc/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-01-28 21:17 UTC (permalink / raw)
To: Alexey Budankov
Cc: Song Liu, Peter Zijlstra, Alexei Starovoitov, Lionel Landwerlin,
james.bottomley@hansenpartnership.com, Paul Mackerras, Jiri Olsa,
Andi Kleen, Igor Lubashev, Alexander Shishkin, Ingo Molnar,
oprofile-list, Serge Hallyn, Robert Richter, Will Deacon,
selinux@vger.kernel.org, intel-gfx@lists.freedesktop.org,
Arnaldo Carvalho de Melo, Stephane Eranian, Namhyung Kim,
linux-arm-kernel, linux-parisc@vger.kernel.org, linux-kernel,
linux-perf-users@vger.kernel.org,
linux-security-module@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3ce8fc61-a61f-5efc-9167-94f5d39b6f1b@linux.intel.com>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index cb50a9e1fd2d..e837717492e4 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -898,7 +898,7 @@ static int thread_imc_event_init(struct perf_event *event)
> if (event->attr.type != event->pmu->type)
> return -ENOENT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EACCES;
>
> /* Sampling not supported */
> @@ -1307,7 +1307,7 @@ static int trace_imc_event_init(struct perf_event *event)
> if (event->attr.type != event->pmu->type)
> return -ENOENT;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
> return -EACCES;
>
> /* Return if this is a couting event */
>
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ 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