* Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
From: Rob Herring @ 2018-10-25 13:15 UTC (permalink / raw)
To: rppt, Ard Biesheuvel
Cc: Linux-MIPS, linux-ia64, SH-Linux, Catalin Marinas, Will Deacon,
devicetree, sparclinux, linux-riscv,
open list:GENERIC INCLUDE/ASM HEADER FILES, linux-s390,
Florian Fainelli, linux-c6x-dev, linux-hexagon, arcml,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
Marc Zyngier, linux-um, linux-m68k, Openrisc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-parisc, Greg Kroah-Hartman, linux-kernel@vger.kernel.org,
linux-alpha, Olof Johansson, nios2-dev, linuxppc-dev
In-Reply-To: <20181025093833.GA23607@rapoport-lnx>
+Ard
On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9d9582c..e9ca238 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
> #ifdef CONFIG_BLK_DEV_INITRD
> +
> +static phys_addr_t initrd_start_phys, initrd_end_phys;
> +
> static int __init early_initrd(char *p)
> {
> unsigned long start, size;
> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> - initrd_start = start;
> - initrd_end = start + size;
> + initrd_start_phys = start;
> + initrd_end_phys = end;
> }
> return 0;
> }
> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> + (initrd_start || initrd_start_phys)) {
> + /*
> + * FIXME: ensure proper precendence between
> + * early_initrd and DT when both are present
Command line takes precedence, so just reverse the order.
> + */
> + if (initrd_start) {
> + initrd_start_phys = __phys_to_virt(initrd_start);
> + initrd_end_phys = __phys_to_virt(initrd_end);
AIUI, the original issue was doing the P2V translation was happening
too early and the VA could be wrong if the linear range is adjusted.
So I don't think this would work.
I suppose you could convert the VA back to a PA before any adjustments
and then back to a VA again after. But that's kind of hacky. 2 wrongs
making a right.
> + } else if (initrd_start_phys) {
> + initrd_start = __va(initrd_start_phys);
> + initrd_end = __va(initrd_start_phys);
> + }
> +
> /*
> * Add back the memory we just removed if it results in the
> * initrd to become inaccessible via the linear mapping.
> * Otherwise, this is a no-op
> */
> - u64 base = initrd_start & PAGE_MASK;
> - u64 size = PAGE_ALIGN(initrd_end) - base;
> + u64 base = initrd_start_phys & PAGE_MASK;
> + u64 size = PAGE_ALIGN(initrd_end_phys) - base;
>
> /*
> * We can only add back the initrd memory if we don't end up
> @@ -458,7 +474,7 @@ void __init arm64_memblock_init(void)
> * pagetables with memblock.
> */
> memblock_reserve(__pa_symbol(_text), _end - _text);
> -#ifdef CONFIG_BLK_DEV_INITRD
> +#if 0
> if (initrd_start) {
> memblock_reserve(initrd_start, initrd_end - initrd_start);
>
>
> > Rob
> >
>
> --
> Sincerely yours,
> Mike.
>
^ permalink raw reply
* Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
From: Joel Fernandes @ 2018-10-25 2:09 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-mips, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Catalin Marinas, Dave Hansen, Will Deacon, mhocko, linux-mm,
lokeshgidra, sparclinux, linux-riscv, elfring, Jonas Bonn, kvmarm,
dancol, Yoshinori Sato, linux-xtensa, linux-hexagon, Helge Deller,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), hughd,
James E.J. Bottomley, kasan-dev, anton.ivanov, Ingo Molnar,
Geert Uytterhoeven, Andrey Ryabinin, linux-snps-arc, kernel-team,
Sam Creasey, Fenghua Yu, linux-s390, Jeff Dike, linux-um,
Stefan Kristiansson, Julia Lawall, linux-m68k, Borislav Petkov,
Andy Lutomirski, nios2-dev, Stafford Horne, Guan Xuetao,
Chris Zankel, Tony Luck, Richard Weinberger, linux-parisc, pantin,
Max Filippov, linux-kernel, minchan, Thomas Gleixner, linux-alpha,
Ley Foon Tan, akpm, linuxppc-dev, David S. Miller
In-Reply-To: <20181024125724.yf6frdimjulf35do@kshutemo-mobl1>
On Wed, Oct 24, 2018 at 03:57:24PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
> > On Wed, Oct 24, 2018 at 01:12:56PM +0300, Kirill A. Shutemov wrote:
> > > On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> > > > diff --git a/mm/mremap.c b/mm/mremap.c
> > > > index 9e68a02a52b1..2fd163cff406 100644
> > > > --- a/mm/mremap.c
> > > > +++ b/mm/mremap.c
> > > > @@ -191,6 +191,54 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
> > > > drop_rmap_locks(vma);
> > > > }
> > > >
> > > > +static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
> > > > + unsigned long new_addr, unsigned long old_end,
> > > > + pmd_t *old_pmd, pmd_t *new_pmd, bool *need_flush)
> > > > +{
> > > > + spinlock_t *old_ptl, *new_ptl;
> > > > + struct mm_struct *mm = vma->vm_mm;
> > > > +
> > > > + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK)
> > > > + || old_end - old_addr < PMD_SIZE)
> > > > + return false;
> > > > +
> > > > + /*
> > > > + * The destination pmd shouldn't be established, free_pgtables()
> > > > + * should have release it.
> > > > + */
> > > > + if (WARN_ON(!pmd_none(*new_pmd)))
> > > > + return false;
> > > > +
> > > > + /*
> > > > + * We don't have to worry about the ordering of src and dst
> > > > + * ptlocks because exclusive mmap_sem prevents deadlock.
> > > > + */
> > > > + old_ptl = pmd_lock(vma->vm_mm, old_pmd);
> > > > + if (old_ptl) {
> > >
> > > How can it ever be false?
Kirill,
It cannot, you are right. I'll remove the test.
By the way, there are new changes upstream by Linus which flush the TLB
before releasing the ptlock instead of after. I'm guessing that patch came
about because of reviews of this patch and someone spotted an issue in the
existing code :)
Anyway the patch in concern is:
eb66ae030829 ("mremap: properly flush TLB before releasing the page")
I need to rebase on top of that with appropriate modifications, but I worry
that this patch will slow down performance since we have to flush at every
PMD/PTE move before releasing the ptlock. Where as with my patch, the
intention is to flush only at once in the end of move_page_tables. When I
tried to flush TLB on every PMD move, it was quite slow on my arm64 device [2].
Further observation [1] is, it seems like the move_huge_pmds and move_ptes code
is a bit sub optimal in the sense, we are acquiring and releasing the same
ptlock for a bunch of PMDs if the said PMDs are on the same page-table page
right? Instead we can do better by acquiring and release the ptlock less
often.
I think this observation [1] and the frequent TLB flush issue [2] can be solved
by acquiring the ptlock once for a bunch of PMDs, move them all, then flush
the tlb and then release the ptlock, and then proceed to doing the same thing
for the PMDs in the next page-table page. What do you think?
- Joel
^ permalink raw reply
* Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
From: Joel Fernandes @ 2018-10-25 2:13 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-mips, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Catalin Marinas, Dave Hansen, Will Deacon, mhocko, linux-mm,
lokeshgidra, sparclinux, linux-riscv, elfring, Jonas Bonn, kvmarm,
dancol, Yoshinori Sato, linux-xtensa, linux-hexagon, Helge Deller,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), hughd,
James E.J. Bottomley, kasan-dev, anton.ivanov, Ingo Molnar,
Geert Uytterhoeven, Andrey Ryabinin, linux-snps-arc, kernel-team,
Sam Creasey, Fenghua Yu, linux-s390, Jeff Dike, linux-um,
Stefan Kristiansson, Julia Lawall, linux-m68k, Borislav Petkov,
Andy Lutomirski, nios2-dev, Kirill A. Shutemov, Stafford Horne,
Guan Xuetao, Chris Zankel, Tony Luck, Richard Weinberger,
linux-parisc, pantin, Max Filippov, linux-kernel, minchan,
Thomas Gleixner, linux-alpha, Ley Foon Tan, akpm, linuxppc-dev,
David S. Miller
In-Reply-To: <20181024115733.GN8537@350D>
On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
[...]
> > > + pmd_t pmd;
> > > +
> > > + new_ptl = pmd_lockptr(mm, new_pmd);
>
>
> Looks like this is largely inspired by move_huge_pmd(), I guess a lot of
> the code applies, why not just reuse as much as possible? The same comments
> w.r.t mmap_sem helping protect against lock order issues applies as well.
I thought about this and when I looked into it, it seemed there are subtle
differences that make such sharing not worth it (or not possible).
- Joel
^ permalink raw reply
* Re: [PATCH] seccomp: Add pkru into seccomp_data
From: Michael Sammler @ 2018-10-25 8:39 UTC (permalink / raw)
To: Florian Weimer
Cc: Will Drewry, Kees Cook, linux-api, Ram Pai, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <87zhv3nrr0.fsf@oldenburg.str.redhat.com>
On 10/24/2018 08:06 PM, Florian Weimer wrote:
> * Michael Sammler:
>
>> Add the current value of the PKRU register to data available for
>> seccomp-bpf programs to work on. This allows filters based on the
>> currently enabled protection keys.
>> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
>> index 9efc0e73..e8b9ecfc 100644
>> --- a/include/uapi/linux/seccomp.h
>> +++ b/include/uapi/linux/seccomp.h
>> @@ -52,12 +52,16 @@
>> * @instruction_pointer: at the time of the system call.
>> * @args: up to 6 system call arguments always stored as 64-bit values
>> * regardless of the architecture.
>> + * @pkru: value of the pkru register
>> + * @reserved: pad the structure to a multiple of eight bytes
>> */
>> struct seccomp_data {
>> int nr;
>> __u32 arch;
>> __u64 instruction_pointer;
>> __u64 args[6];
>> + __u32 pkru;
>> + __u32 reserved;
>> };
> This doesn't cover the POWER implementation. Adding Cc:s.
>
> And I think the kernel shouldn't expose the number of protection keys in
> the ABI.
>
> Thanks,
> Florian
Thank you for the pointer about the POWER implementation. I am not
familiar with POWER in general and its protection key feature at all.
Would the AMR register be the correct register to expose here?
I understand your concern about exposing the number of protection keys
in the ABI. One idea would be to state, that the pkru field (which
should probably be renamed) contains an architecture specific value,
which could then be the PKRU on x86 and AMR (or another register) on
POWER. This new field should probably be extended to __u64 and the
reserved field removed.
Another idea would be to not add a field in the seccomp_data structure,
but instead provide a new BPF instruction, which reads the value of a
specified protection key.
- Michael
^ permalink raw reply
* Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
From: Kirill A. Shutemov @ 2018-10-25 10:19 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-mips, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Catalin Marinas, Dave Hansen, Will Deacon, mhocko, linux-mm,
lokeshgidra, sparclinux, linux-riscv, elfring, Jonas Bonn, kvmarm,
dancol, Yoshinori Sato, linux-xtensa, linux-hexagon, Helge Deller,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), hughd,
James E.J. Bottomley, kasan-dev, anton.ivanov, Ingo Molnar,
Geert Uytterhoeven, Andrey Ryabinin, linux-snps-arc, kernel-team,
Sam Creasey, Fenghua Yu, linux-s390, Jeff Dike, linux-um,
Stefan Kristiansson, Julia Lawall, linux-m68k, Borislav Petkov,
Andy Lutomirski, nios2-dev, Stafford Horne, Guan Xuetao,
Chris Zankel, Tony Luck, Richard Weinberger, linux-parisc, pantin,
Max Filippov, linux-kernel, minchan, Thomas Gleixner, linux-alpha,
Ley Foon Tan, akpm, linuxppc-dev, David S. Miller
In-Reply-To: <20181025020907.GA13560@joelaf.mtv.corp.google.com>
On Wed, Oct 24, 2018 at 07:09:07PM -0700, Joel Fernandes wrote:
> On Wed, Oct 24, 2018 at 03:57:24PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
> > > On Wed, Oct 24, 2018 at 01:12:56PM +0300, Kirill A. Shutemov wrote:
> > > > On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> > > > > diff --git a/mm/mremap.c b/mm/mremap.c
> > > > > index 9e68a02a52b1..2fd163cff406 100644
> > > > > --- a/mm/mremap.c
> > > > > +++ b/mm/mremap.c
> > > > > @@ -191,6 +191,54 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
> > > > > drop_rmap_locks(vma);
> > > > > }
> > > > >
> > > > > +static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
> > > > > + unsigned long new_addr, unsigned long old_end,
> > > > > + pmd_t *old_pmd, pmd_t *new_pmd, bool *need_flush)
> > > > > +{
> > > > > + spinlock_t *old_ptl, *new_ptl;
> > > > > + struct mm_struct *mm = vma->vm_mm;
> > > > > +
> > > > > + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK)
> > > > > + || old_end - old_addr < PMD_SIZE)
> > > > > + return false;
> > > > > +
> > > > > + /*
> > > > > + * The destination pmd shouldn't be established, free_pgtables()
> > > > > + * should have release it.
> > > > > + */
> > > > > + if (WARN_ON(!pmd_none(*new_pmd)))
> > > > > + return false;
> > > > > +
> > > > > + /*
> > > > > + * We don't have to worry about the ordering of src and dst
> > > > > + * ptlocks because exclusive mmap_sem prevents deadlock.
> > > > > + */
> > > > > + old_ptl = pmd_lock(vma->vm_mm, old_pmd);
> > > > > + if (old_ptl) {
> > > >
> > > > How can it ever be false?
>
> Kirill,
> It cannot, you are right. I'll remove the test.
>
> By the way, there are new changes upstream by Linus which flush the TLB
> before releasing the ptlock instead of after. I'm guessing that patch came
> about because of reviews of this patch and someone spotted an issue in the
> existing code :)
>
> Anyway the patch in concern is:
> eb66ae030829 ("mremap: properly flush TLB before releasing the page")
>
> I need to rebase on top of that with appropriate modifications, but I worry
> that this patch will slow down performance since we have to flush at every
> PMD/PTE move before releasing the ptlock. Where as with my patch, the
> intention is to flush only at once in the end of move_page_tables. When I
> tried to flush TLB on every PMD move, it was quite slow on my arm64 device [2].
>
> Further observation [1] is, it seems like the move_huge_pmds and move_ptes code
> is a bit sub optimal in the sense, we are acquiring and releasing the same
> ptlock for a bunch of PMDs if the said PMDs are on the same page-table page
> right? Instead we can do better by acquiring and release the ptlock less
> often.
>
> I think this observation [1] and the frequent TLB flush issue [2] can be solved
> by acquiring the ptlock once for a bunch of PMDs, move them all, then flush
> the tlb and then release the ptlock, and then proceed to doing the same thing
> for the PMDs in the next page-table page. What do you think?
Yeah, that's viable optimization.
The tricky part is that one PMD page table can have PMD entires of
different types: THP, page table that you can move as whole and the one
that you cannot (for any reason).
If we cannot move the PMD entry as a whole and must go to PTE page table
we would need to drop PMD ptl and take PTE ptl (it might be the same lock
in some configuations).
Also we don't want to take PMD lock unless it's required.
I expect it to be not very trivial to get everything right. But take a
shot :)
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH] powerpc/process: Fix flush_all_to_thread for SPE
From: DATACOM - Felipe.Rechia @ 2018-10-25 12:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Zaneti
From: "Felipe Rechia" <felipe.rechia@datacom.com.br>
Date: Wed, 24 Oct 2018 10:57:22 -0300
Subject: [PATCH] powerpc/process: Fix flush_all_to_thread for SPE
Fix a bug introduced by the creation of flush_all_to_thread() for
processors that have SPE (Signal Processing Engine) and use it to
compute floating-point operations.
From userspace perspective, the problem was seen in attempts of
computing floating-point operations which should generate exceptions.
For example:
fork();
float x = 0.0 / 0.0;
isnan(x); // forked process returns False (should be True)
The operation above also should always cause the SPEFSCR FINV bit to
be set. However, the SPE floating-point exceptions were turned off
after a fork().
Kernel versions prior to the bug used flush_spe_to_thread(), which
first saves SPEFSCR register values in tsk->thread and then calls
giveup_spe(tsk).
After commit 579e633e764e, the save_all() function was called first
to giveup_spe(), and then the SPEFSCR register values were saved in
tsk->thread. This would save the SPEFSCR register values after
disabling SPE for that thread, causing the bug described above.
Fixes 579e633e764e ("powerpc: create flush_all_to_thread()")
Signed-off-by: felipe.rechia <felipe.rechia@datacom.com.br>
---
arch/powerpc/kernel/process.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a0c74bb..16eb428 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -566,12 +566,11 @@ void flush_all_to_thread(struct task_struct *tsk)
if (tsk->thread.regs) {
preempt_disable();
BUG_ON(tsk != current);
- save_all(tsk);
-
#ifdef CONFIG_SPE
if (tsk->thread.regs->msr & MSR_SPE)
tsk->thread.spefscr = mfspr(SPRN_SPEFSCR);
#endif
+ save_all(tsk);
preempt_enable();
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 00/18] of: overlay: validation checks, subsequent fixes
From: Alan Tull @ 2018-10-25 15:25 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-fpga, linuxppc-dev, Pantelis Antoniou, linux-kernel,
Moritz Fischer, Paul Mackerras, Frank Rowand
In-Reply-To: <CAL_JsqJ1=5ABi5N50HLTSu2xFGJJSf-6EpuvhkG-rxSbv3MZdw@mail.gmail.com>
On Wed, Oct 24, 2018 at 2:57 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Oct 22, 2018 at 4:25 PM Alan Tull <atull@kernel.org> wrote:
> >
> > On Thu, Oct 18, 2018 at 5:48 PM <frowand.list@gmail.com> wrote:
> > >
> > > From: Frank Rowand <frank.rowand@sony.com>
> > >
> > > Add checks to (1) overlay apply process and (2) memory freeing
> > > triggered by overlay release. The checks are intended to detect
> > > possible memory leaks and invalid overlays.
> >
> > I've tested v5, nothing new to report.
>
> Does that mean everything broken or everything works great? In the
> latter case, care to give a Tested-by.
>
> Rob
Tested-by: Alan Tull <atull@kernel.org>
Alan
^ permalink raw reply
* Re: [PATCH] seccomp: Add pkru into seccomp_data
From: Michael Sammler @ 2018-10-25 16:42 UTC (permalink / raw)
To: Florian Weimer
Cc: Will Drewry, Kees Cook, linux-api, Ram Pai, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <875zxqo0ee.fsf@oldenburg.str.redhat.com>
On 10/25/2018 11:12 AM, Florian Weimer wrote:
>> I understand your concern about exposing the number of protection keys
>> in the ABI. One idea would be to state, that the pkru field (which
>> should probably be renamed) contains an architecture specific value,
>> which could then be the PKRU on x86 and AMR (or another register) on
>> POWER. This new field should probably be extended to __u64 and the
>> reserved field removed.
> POWER also has proper read/write bit separation, not PKEY_DISABLE_ACCESS
> (disable read and write) and PKEY_DISABLE_WRITE like Intel. It's
> currently translated by the kernel, but I really need a
> PKEY_DISABLE_READ bit in glibc to implement pkey_get in case the memory
> is write-only.
The idea here would be to simply provide the raw value of the register
(PKRU on x86, AMR on POWER) to the BPF program and let the BPF program
(or maybe a higher level library like libseccomp) deal with the
complications of interpreting this architecture specific value (similar
how the BPF program currently already has to deal with architecture
specific system call numbers). If an architecture were to support more
protection keys than fit into the field, the architecture specific value
stored in the field might simply be the first protection keys. If there
was interest, it would be possible to add more architecture specific
fields to seccomp_data.
>> Another idea would be to not add a field in the seccomp_data
>> structure, but instead provide a new BPF instruction, which reads the
>> value of a specified protection key.
> I would prefer that if it's possible. We should make sure that the bits
> are the same as those returned from pkey_get. I have an implementation
> on POWER, but have yet to figure out the implications for 32-bit because
> I do not know the AMR register size there.
>
> Thanks,
> Florian
I have had a look at how BPF is implemented and it does not seem to be
easy to just add an BPF instruction for seccomp since (as far as I
understand) the code of the classical BPF (as used by seccomp) is shared
with the code of eBPF, which is used in many parts of the kernel and
there is at least one interpreter and one JIT compiler for BPF. But
maybe someone with more experience than me can comment on how hard it
would be to add an instruction to BPF.
- Michael
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
From: Mike Rapoport @ 2018-10-25 17:29 UTC (permalink / raw)
To: Rob Herring
Cc: Linux-MIPS, linux-ia64, SH-Linux, Catalin Marinas, Will Deacon,
devicetree, sparclinux, linux-riscv,
open list:GENERIC INCLUDE/ASM HEADER FILES, linux-s390,
Florian Fainelli, linux-c6x-dev, linux-hexagon, arcml,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
Marc Zyngier, linux-um, linux-m68k, Openrisc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-parisc, Ard Biesheuvel, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, linux-alpha, Olof Johansson,
nios2-dev, linuxppc-dev
In-Reply-To: <CAL_JsqL62ttsGSbE1BS5v-mX3pKE-p_HyvuZD6nB+GUbQyetzg@mail.gmail.com>
On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> +Ard
>
> On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > because we define __early_init_dt_declare_initrd() differently and we do
> > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > amount of other header files, and translation units as well.
> > >
> > > I scratch my head sometimes as to why some config options rebuild so
> > > much stuff. One down, ? to go. :)
> > >
> > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > > systems that generate two kernels: one with the initramfs and one
> > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > another one that does this.
> > > >
> > > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > > custom __early_init_dt_declare_initrd() definition away from
> > > > asm/memory.h
> > > >
> > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > factor 73 approximately.
> > > >
> > > > Apologies for the long CC list, please let me know how you would go
> > > > about merging that and if another approach would be preferable, e.g:
> > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > something like that.
> > >
> > > There may be a better way as of 4.20 because bootmem is now gone and
> > > only memblock is used. This should unify what each arch needs to do
> > > with initrd early. We need the physical address early for memblock
> > > reserving. Then later on we need the virtual address to access the
> > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > physical addresses (or add 2 new variables would be less invasive and
> > > allow for different translation than __va()). The sanity checks and
> > > memblock reserve could also perhaps be moved to a common location.
> > >
> > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > it like the above option.
> >
> > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > Something like this might be just all we need (completely untested,
> > probably it won't even compile):
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 9d9582c..e9ca238 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > phys_addr_t arm64_dma_phys_limit __ro_after_init;
> >
> > #ifdef CONFIG_BLK_DEV_INITRD
> > +
> > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > +
> > static int __init early_initrd(char *p)
> > {
> > unsigned long start, size;
> > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > if (*endp == ',') {
> > size = memparse(endp + 1, NULL);
> >
> > - initrd_start = start;
> > - initrd_end = start + size;
> > + initrd_start_phys = start;
> > + initrd_end_phys = end;
> > }
> > return 0;
> > }
> > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> > }
> >
> > - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> > + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> > + (initrd_start || initrd_start_phys)) {
> > + /*
> > + * FIXME: ensure proper precendence between
> > + * early_initrd and DT when both are present
>
> Command line takes precedence, so just reverse the order.
>
> > + */
> > + if (initrd_start) {
> > + initrd_start_phys = __phys_to_virt(initrd_start);
> > + initrd_end_phys = __phys_to_virt(initrd_end);
>
> AIUI, the original issue was doing the P2V translation was happening
> too early and the VA could be wrong if the linear range is adjusted.
> So I don't think this would work.
Probably things have changed since then, but in the current code there is
initrd_start = __phys_to_virt(initrd_start);
and in between only the code related to CONFIG_RANDOMIZE_BASE, so I believe
it's safe to use __phys_to_virt() here as well.
> I suppose you could convert the VA back to a PA before any adjustments
> and then back to a VA again after. But that's kind of hacky. 2 wrongs
> making a right.
>
> > + } else if (initrd_start_phys) {
> > + initrd_start = __va(initrd_start_phys);
> > + initrd_end = __va(initrd_start_phys);
> > + }
> > +
> > /*
> > * Add back the memory we just removed if it results in the
> > * initrd to become inaccessible via the linear mapping.
> > * Otherwise, this is a no-op
> > */
> > - u64 base = initrd_start & PAGE_MASK;
> > - u64 size = PAGE_ALIGN(initrd_end) - base;
> > + u64 base = initrd_start_phys & PAGE_MASK;
> > + u64 size = PAGE_ALIGN(initrd_end_phys) - base;
> >
> > /*
> > * We can only add back the initrd memory if we don't end up
> > @@ -458,7 +474,7 @@ void __init arm64_memblock_init(void)
> > * pagetables with memblock.
> > */
> > memblock_reserve(__pa_symbol(_text), _end - _text);
> > -#ifdef CONFIG_BLK_DEV_INITRD
> > +#if 0
> > if (initrd_start) {
> > memblock_reserve(initrd_start, initrd_end - initrd_start);
> >
> >
> > > Rob
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v6 5/6] arm64: dts: add QorIQ LX2160A SoC support
From: Li Yang @ 2018-10-25 19:49 UTC (permalink / raw)
To: Vabhav Sharma
Cc: Mark Rutland, Kate Stewart, Ulf Hansson, yogeshnarayan.gaur,
linux-kernel-owner, Catalin Marinas, Michael Turquette,
Will Deacon, Adrian Hunter, yamada.masahiro, Sriram Dash,
linux-clk, Horia Geanta, pankaj.bansal, udit.kumar, Russell King,
Priyanka Jain, Viresh Kumar, Yinbo Zhu,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-pm, linuxppc-dev, Scott Wood, Rob Herring,
V.Sethi, nipun.gupta,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Ramneek Mehresh, sboyd, Greg Kroah-Hartman, Ying Zhang,
Rafael J. Wysocki, lkml, Sudeep Holla, Ran Wang, Shawn Guo
In-Reply-To: <1540407376-24115-6-git-send-email-vabhav.sharma@nxp.com>
On Thu, Oct 25, 2018 at 2:03 AM Vabhav Sharma <vabhav.sharma@nxp.com> wrote:
>
> LX2160A SoC is based on Layerscape Chassis Generation 3.2 Architecture.
>
> LX2160A features an advanced 16 64-bit ARM v8 CortexA72 processor cores
> in 8 cluster, CCN508, GICv3,two 64-bit DDR4 memory controller, 8 I2C
> controllers, 3 dspi, 2 esdhc,2 USB 3.0, mmu 500, 3 SATA, 4 PL011 SBSA
> UARTs etc.
>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@nxp.com>
> Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> Signed-off-by: Horia Geanta <horia.geanta@nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 766 +++++++++++++++++++++++++
> 1 file changed, 766 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> new file mode 100644
> index 0000000..9fcfd48
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -0,0 +1,766 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +//
> +// Device Tree Include file for Layerscape-LX2160A family SoC.
> +//
> +// Copyright 2018 NXP
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/memreserve/ 0x80000000 0x00010000;
> +
> +/ {
> + compatible = "fsl,lx2160a";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + // 8 clusters having 2 Cortex-A72 cores each
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x0>;
> + clocks = <&clockgen 1 0>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster0_l2>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x1>;
> + clocks = <&clockgen 1 0>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster0_l2>;
> + };
> +
> + cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x100>;
> + clocks = <&clockgen 1 1>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster1_l2>;
> + };
> +
> + cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x101>;
> + clocks = <&clockgen 1 1>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster1_l2>;
> + };
> +
> + cpu@200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x200>;
> + clocks = <&clockgen 1 2>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster2_l2>;
> + };
> +
> + cpu@201 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x201>;
> + clocks = <&clockgen 1 2>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster2_l2>;
> + };
> +
> + cpu@300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x300>;
> + clocks = <&clockgen 1 3>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster3_l2>;
> + };
> +
> + cpu@301 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x301>;
> + clocks = <&clockgen 1 3>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster3_l2>;
> + };
> +
> + cpu@400 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x400>;
> + clocks = <&clockgen 1 4>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster4_l2>;
> + };
> +
> + cpu@401 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x401>;
> + clocks = <&clockgen 1 4>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster4_l2>;
> + };
> +
> + cpu@500 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x500>;
> + clocks = <&clockgen 1 5>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster5_l2>;
> + };
> +
> + cpu@501 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x501>;
> + clocks = <&clockgen 1 5>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster5_l2>;
> + };
> +
> + cpu@600 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x600>;
> + clocks = <&clockgen 1 6>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster6_l2>;
> + };
> +
> + cpu@601 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x601>;
> + clocks = <&clockgen 1 6>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster6_l2>;
> + };
> +
> + cpu@700 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x700>;
> + clocks = <&clockgen 1 7>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster7_l2>;
> + };
> +
> + cpu@701 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + enable-method = "psci";
> + reg = <0x701>;
> + clocks = <&clockgen 1 7>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + i-cache-size = <0xC000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <192>;
> + next-level-cache = <&cluster7_l2>;
> + };
> +
> + cluster0_l2: l2-cache0 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster1_l2: l2-cache1 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster2_l2: l2-cache2 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster3_l2: l2-cache3 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster4_l2: l2-cache4 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster5_l2: l2-cache5 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster6_l2: l2-cache6 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> +
> + cluster7_l2: l2-cache7 {
> + compatible = "cache";
> + cache-size = <0x100000>;
> + cache-line-size = <64>;
> + cache-sets = <1024>;
> + cache-level = <2>;
> + };
> + };
> +
> + gic: interrupt-controller@6000000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x06000000 0 0x10000>, // GIC Dist
> + <0x0 0x06200000 0 0x200000>, // GICR (RD_base +
> + // SGI_base)
> + <0x0 0x0c0c0000 0 0x2000>, // GICC
> + <0x0 0x0c0d0000 0 0x1000>, // GICH
> + <0x0 0x0c0e0000 0 0x20000>; // GICV
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + interrupt-controller;
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + its: gic-its@6020000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + reg = <0x0 0x6020000 0 0x20000>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a72-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + memory@80000000 {
> + // DRAM space - 1, size : 2 GB DRAM
> + device_type = "memory";
> + reg = <0x00000000 0x80000000 0 0x80000000>;
> + };
> +
> + ddr1: memory-controller@1080000 {
> + compatible = "fsl,qoriq-memory-controller";
> + reg = <0x0 0x1080000 0x0 0x1000>;
> + interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> + };
> +
> + ddr2: memory-controller@1090000 {
> + compatible = "fsl,qoriq-memory-controller";
> + reg = <0x0 0x1090000 0x0 0x1000>;
> + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> + little-endian;
> + };
> +
> + // One clock unit-sysclk node which bootloader require during DT fix-up
> + sysclk: sysclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
Would be even better if you can add a comment "fixed up by bootloader"
to the property too.
> + clock-output-names = "sysclk";
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + crypto: crypto@8000000 {
> + compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
> + fsl,sec-era = <10>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x8000000 0x100000>;
> + reg = <0x00 0x8000000 0x0 0x100000>;
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> + dma-coherent;
> + status = "disabled";
> +
> + sec_jr0: jr@10000 {
> + compatible = "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x10000 0x10000>;
> + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr1: jr@20000 {
> + compatible = "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x20000 0x10000>;
> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr2: jr@30000 {
> + compatible = "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x30000 0x10000>;
> + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr3: jr@40000 {
> + compatible = "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x40000 0x10000>;
> + interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> + clockgen: clock-controller@1300000 {
> + compatible = "fsl,lx2160a-clockgen";
> + reg = <0 0x1300000 0 0xa0000>;
> + #clock-cells = <2>;
> + clocks = <&sysclk>;
> + };
> +
> + dcfg: syscon@1e00000 {
> + compatible = "fsl,lx2160a-dcfg", "syscon";
> + reg = <0x0 0x1e00000 0x0 0x10000>;
> + little-endian;
> + };
> +
> + i2c0: i2c@2000000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2000000 0x0 0x10000>;
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + scl-gpio = <&gpio2 15 GPIO_ACTIVE_HIGH>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@2010000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2010000 0x0 0x10000>;
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@2020000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2020000 0x0 0x10000>;
> + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@2030000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2030000 0x0 0x10000>;
> + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c@2040000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2040000 0x0 0x10000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + scl-gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>;
> + status = "disabled";
> + };
> +
> + i2c5: i2c@2050000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2050000 0x0 0x10000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + i2c6: i2c@2060000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2060000 0x0 0x10000>;
> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + i2c7: i2c@2070000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2070000 0x0 0x10000>;
> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "i2c";
> + clocks = <&clockgen 4 7>;
> + status = "disabled";
> + };
> +
> + esdhc0: esdhc@2140000 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x2140000 0x0 0x10000>;
> + interrupts = <0 28 0x4>; /* Level high type */
> + clocks = <&clockgen 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + esdhc1: esdhc@2150000 {
> + compatible = "fsl,esdhc";
> + reg = <0x0 0x2150000 0x0 0x10000>;
> + interrupts = <0 63 0x4>; /* Level high type */
> + clocks = <&clockgen 4 1>;
> + voltage-ranges = <1800 1800 3300 3300>;
> + sdhci,auto-cmd12;
> + broken-cd;
> + little-endian;
> + bus-width = <4>;
> + status = "disabled";
> + };
> +
> + uart0: serial@21c0000 {
> + compatible = "arm,sbsa-uart","arm,pl011";
> + reg = <0x0 0x21c0000 0x0 0x1000>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + uart1: serial@21d0000 {
> + compatible = "arm,sbsa-uart","arm,pl011";
> + reg = <0x0 0x21d0000 0x0 0x1000>;
> + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + uart2: serial@21e0000 {
> + compatible = "arm,sbsa-uart","arm,pl011";
> + reg = <0x0 0x21e0000 0x0 0x1000>;
> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + uart3: serial@21f0000 {
> + compatible = "arm,sbsa-uart","arm,pl011";
> + reg = <0x0 0x21f0000 0x0 0x1000>;
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + gpio0: gpio@2300000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2300000 0x0 0x10000>;
> + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + little-endian;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio1: gpio@2310000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2310000 0x0 0x10000>;
> + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + little-endian;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio2: gpio@2320000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2320000 0x0 0x10000>;
> + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + little-endian;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio3: gpio@2330000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2330000 0x0 0x10000>;
> + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + little-endian;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + watchdog@23a0000 {
> + compatible = "arm,sbsa-gwdt";
> + reg = <0x0 0x23a0000 0 0x1000>,
> + <0x0 0x2390000 0 0x1000>;
> + interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
> + timeout-sec = <30>;
> + };
> +
> + usb0: usb@3100000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3100000 0x0 0x10000>;
> + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + usb1: usb@3110000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3110000 0x0 0x10000>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + smmu: iommu@5000000 {
> + compatible = "arm,mmu-500";
> + reg = <0 0x5000000 0 0x800000>;
> + #iommu-cells = <1>;
> + #global-interrupts = <14>;
> + // global secure fault
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
> + // combined secure
> + <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
> + // global non-secure fault
> + <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
> + // combined non-secure
> + <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> + // performance counter interrupts 0-9
> + <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
> + // per context interrupt, 64 interrupts
> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> + dma-coherent;
> + };
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v1 0/5] Add dtl_entry tracepoint
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
This is v1 of the patches for providing a tracepoint for processing the
dispatch trace log entries from the hypervisor in a shared processor
LPAR. The previous RFC can be found here:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=66340
Since the RFC, this series has been expanded/generalized to support
!CONFIG_VIRT_CPU_ACCOUNTING_NATIVE and has been tested in different
configurations. The dispatch distance calculation has also been updated
to use the platform provided information better.
Also, patch 3 is new and fixes an issue with stolen time accounting when
the dtl debugfs interface is in use.
- Naveen
Naveen N. Rao (5):
powerpc/pseries: Use macros for referring to the DTL enable mask
powerpc/pseries: Do not save the previous DTL mask value
powerpc/pseries: Fix stolen time accounting when dtl debugfs is used
powerpc/pseries: Factor out DTL buffer allocation and registration
routines
powerpc/pseries: Introduce dtl_entry tracepoint
arch/powerpc/include/asm/lppaca.h | 11 +
arch/powerpc/include/asm/plpar_wrappers.h | 9 +
arch/powerpc/include/asm/trace.h | 55 +++++
arch/powerpc/kernel/entry_64.S | 39 ++++
arch/powerpc/kernel/time.c | 7 +-
arch/powerpc/mm/numa.c | 144 ++++++++++++-
arch/powerpc/platforms/pseries/dtl.c | 22 +-
arch/powerpc/platforms/pseries/lpar.c | 249 ++++++++++++++++++++--
arch/powerpc/platforms/pseries/setup.c | 34 +--
9 files changed, 502 insertions(+), 68 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH v1 1/5] powerpc/pseries: Use macros for referring to the DTL enable mask
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
In-Reply-To: <cover.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
Introduce macros to encode the DTL enable mask fields and use those
instead of hardcoding numbers.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/lppaca.h | 11 +++++++++++
arch/powerpc/platforms/pseries/dtl.c | 8 +-------
arch/powerpc/platforms/pseries/lpar.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index 7c23ce8a5a4c..2c7e31187726 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -154,6 +154,17 @@ struct dtl_entry {
#define DISPATCH_LOG_BYTES 4096 /* bytes per cpu */
#define N_DISPATCH_LOG (DISPATCH_LOG_BYTES / sizeof(struct dtl_entry))
+/*
+ * Dispatch trace log event enable mask:
+ * 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+#define DTL_LOG_CEDE 0x1
+#define DTL_LOG_PREEMPT 0x2
+#define DTL_LOG_FAULT 0x4
+#define DTL_LOG_ALL (DTL_LOG_CEDE | DTL_LOG_PREEMPT | DTL_LOG_FAULT)
+
extern struct kmem_cache *dtl_cache;
/*
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
index ef6595153642..051ea2de1e1a 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -40,13 +40,7 @@ struct dtl {
};
static DEFINE_PER_CPU(struct dtl, cpu_dtl);
-/*
- * Dispatch trace log event mask:
- * 0x7: 0x1: voluntary virtual processor waits
- * 0x2: time-slice preempts
- * 0x4: virtual partition memory page faults
- */
-static u8 dtl_event_mask = 0x7;
+static u8 dtl_event_mask = DTL_LOG_ALL;
/*
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 0b5081085a44..ad194420e8ae 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -125,7 +125,7 @@ void vpa_init(int cpu)
pr_err("WARNING: DTL registration of cpu %d (hw %d) "
"failed with %ld\n", smp_processor_id(),
hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = 2;
+ lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
}
}
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0f553dcfa548..f3b5822e88c6 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -306,7 +306,7 @@ static int alloc_dispatch_logs(void)
pr_err("WARNING: DTL registration of cpu %d (hw %d) failed "
"with %d\n", smp_processor_id(),
hard_smp_processor_id(), ret);
- get_paca()->lppaca_ptr->dtl_enable_mask = 2;
+ get_paca()->lppaca_ptr->dtl_enable_mask = DTL_LOG_PREEMPT;
return 0;
}
--
2.19.1
^ permalink raw reply related
* [PATCH v1 2/5] powerpc/pseries: Do not save the previous DTL mask value
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
In-Reply-To: <cover.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is enabled, we always initialize
DTL enable mask to DTL_LOG_PREEMPT (0x2). There are no other places
where the mask is changed. As such, when reading the DTL log buffer
through debugfs, there is no need to save and restore the previous mask
value.
We don't need to save and restore the earlier mask value if
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not enabled. So, remove the field
from the structure as well.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dtl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
index 051ea2de1e1a..fb05804adb2f 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -55,7 +55,6 @@ struct dtl_ring {
struct dtl_entry *write_ptr;
struct dtl_entry *buf;
struct dtl_entry *buf_end;
- u8 saved_dtl_mask;
};
static DEFINE_PER_CPU(struct dtl_ring, dtl_rings);
@@ -105,7 +104,6 @@ static int dtl_start(struct dtl *dtl)
dtlr->write_ptr = dtl->buf;
/* enable event logging */
- dtlr->saved_dtl_mask = lppaca_of(dtl->cpu).dtl_enable_mask;
lppaca_of(dtl->cpu).dtl_enable_mask |= dtl_event_mask;
dtl_consumer = consume_dtle;
@@ -123,7 +121,7 @@ static void dtl_stop(struct dtl *dtl)
dtlr->buf = NULL;
/* restore dtl_enable_mask */
- lppaca_of(dtl->cpu).dtl_enable_mask = dtlr->saved_dtl_mask;
+ lppaca_of(dtl->cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
if (atomic_dec_and_test(&dtl_count))
dtl_consumer = NULL;
--
2.19.1
^ permalink raw reply related
* [PATCH v1 3/5] powerpc/pseries: Fix stolen time accounting when dtl debugfs is used
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
In-Reply-To: <cover.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
When the dtl debugfs interface is used, we usually set the
dtl_enable_mask to 0x7 (DTL_LOG_ALL). When this happens, we start seeing
DTL entries for all preempt reasons, including CEDE. In
scan_dispatch_log(), we add up the times from all entries and account
those towards stolen time. However, we should only be accounting stolen
time when the preemption was due to HDEC at the end of our time slice.
Fix this by checking for the dispatch reason in the DTL entry before
adding to the stolen time.
Fixes: cf9efce0ce313 ("powerpc: Account time using timebase rather than PURR")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/time.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 40868f3ee113..923abc3e555d 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -199,7 +199,7 @@ static u64 scan_dispatch_log(u64 stop_tb)
struct lppaca *vpa = local_paca->lppaca_ptr;
u64 tb_delta;
u64 stolen = 0;
- u64 dtb;
+ u64 dtb, dispatch_reason;
if (!dtl)
return 0;
@@ -210,6 +210,7 @@ static u64 scan_dispatch_log(u64 stop_tb)
dtb = be64_to_cpu(dtl->timebase);
tb_delta = be32_to_cpu(dtl->enqueue_to_dispatch_time) +
be32_to_cpu(dtl->ready_to_enqueue_time);
+ dispatch_reason = dtl->dispatch_reason;
barrier();
if (i + N_DISPATCH_LOG < be64_to_cpu(vpa->dtl_idx)) {
/* buffer has overflowed */
@@ -221,7 +222,9 @@ static u64 scan_dispatch_log(u64 stop_tb)
break;
if (dtl_consumer)
dtl_consumer(dtl, i);
- stolen += tb_delta;
+ /* 7 indicates that this dispatch follows a time slice preempt */
+ if (dispatch_reason == 7)
+ stolen += tb_delta;
++i;
++dtl;
if (dtl == dtl_end)
--
2.19.1
^ permalink raw reply related
* [PATCH v1 4/5] powerpc/pseries: Factor out DTL buffer allocation and registration routines
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
In-Reply-To: <cover.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
Introduce new helpers for DTL buffer allocation and registration and
have the existing code use those.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/plpar_wrappers.h | 2 +
arch/powerpc/platforms/pseries/lpar.c | 66 ++++++++++++++++-------
arch/powerpc/platforms/pseries/setup.c | 34 +-----------
3 files changed, 52 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index cff5a411e595..7dcbf42e9e11 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -88,6 +88,8 @@ static inline long register_dtl(unsigned long cpu, unsigned long vpa)
return vpa_call(H_VPA_REG_DTL, cpu, vpa);
}
+extern void alloc_dtl_buffers(void);
+extern void register_dtl_buffer(int cpu);
extern void vpa_init(int cpu);
static inline long plpar_pte_enter(unsigned long flags,
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index ad194420e8ae..d83bb3db6767 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -64,13 +64,58 @@ EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall9);
EXPORT_SYMBOL(plpar_hcall_norets);
+void alloc_dtl_buffers(void)
+{
+ int cpu;
+ struct paca_struct *pp;
+ struct dtl_entry *dtl;
+
+ for_each_possible_cpu(cpu) {
+ pp = paca_ptrs[cpu];
+ dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
+ if (!dtl) {
+ pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
+ cpu);
+ pr_warn("Stolen time statistics will be unreliable\n");
+ break;
+ }
+
+ pp->dtl_ridx = 0;
+ pp->dispatch_log = dtl;
+ pp->dispatch_log_end = dtl + N_DISPATCH_LOG;
+ pp->dtl_curr = dtl;
+ }
+}
+
+void register_dtl_buffer(int cpu)
+{
+ long ret;
+ struct paca_struct *pp;
+ struct dtl_entry *dtl;
+ int hwcpu = get_hard_smp_processor_id(cpu);
+
+ pp = paca_ptrs[cpu];
+ dtl = pp->dispatch_log;
+ if (dtl) {
+ pp->dtl_ridx = 0;
+ pp->dtl_curr = dtl;
+ lppaca_of(cpu).dtl_idx = 0;
+
+ /* hypervisor reads buffer length from this field */
+ dtl->enqueue_to_dispatch_time = cpu_to_be32(DISPATCH_LOG_BYTES);
+ ret = register_dtl(hwcpu, __pa(dtl));
+ if (ret)
+ pr_err("WARNING: DTL registration of cpu %d (hw %d) "
+ "failed with %ld\n", cpu, hwcpu, ret);
+ lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
+ }
+}
+
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
unsigned long addr;
long ret;
- struct paca_struct *pp;
- struct dtl_entry *dtl;
/*
* The spec says it "may be problematic" if CPU x registers the VPA of
@@ -111,22 +156,7 @@ void vpa_init(int cpu)
/*
* Register dispatch trace log, if one has been allocated.
*/
- pp = paca_ptrs[cpu];
- dtl = pp->dispatch_log;
- if (dtl) {
- pp->dtl_ridx = 0;
- pp->dtl_curr = dtl;
- lppaca_of(cpu).dtl_idx = 0;
-
- /* hypervisor reads buffer length from this field */
- dtl->enqueue_to_dispatch_time = cpu_to_be32(DISPATCH_LOG_BYTES);
- ret = register_dtl(hwcpu, __pa(dtl));
- if (ret)
- pr_err("WARNING: DTL registration of cpu %d (hw %d) "
- "failed with %ld\n", smp_processor_id(),
- hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
- }
+ register_dtl_buffer(cpu);
}
#ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index f3b5822e88c6..be6a3845b7ea 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -267,46 +267,16 @@ struct kmem_cache *dtl_cache;
*/
static int alloc_dispatch_logs(void)
{
- int cpu, ret;
- struct paca_struct *pp;
- struct dtl_entry *dtl;
-
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
if (!dtl_cache)
return 0;
- for_each_possible_cpu(cpu) {
- pp = paca_ptrs[cpu];
- dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
- if (!dtl) {
- pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
- cpu);
- pr_warn("Stolen time statistics will be unreliable\n");
- break;
- }
-
- pp->dtl_ridx = 0;
- pp->dispatch_log = dtl;
- pp->dispatch_log_end = dtl + N_DISPATCH_LOG;
- pp->dtl_curr = dtl;
- }
+ alloc_dtl_buffers();
/* Register the DTL for the current (boot) cpu */
- dtl = get_paca()->dispatch_log;
- get_paca()->dtl_ridx = 0;
- get_paca()->dtl_curr = dtl;
- get_paca()->lppaca_ptr->dtl_idx = 0;
-
- /* hypervisor reads buffer length from this field */
- dtl->enqueue_to_dispatch_time = cpu_to_be32(DISPATCH_LOG_BYTES);
- ret = register_dtl(hard_smp_processor_id(), __pa(dtl));
- if (ret)
- pr_err("WARNING: DTL registration of cpu %d (hw %d) failed "
- "with %d\n", smp_processor_id(),
- hard_smp_processor_id(), ret);
- get_paca()->lppaca_ptr->dtl_enable_mask = DTL_LOG_PREEMPT;
+ register_dtl_buffer(smp_processor_id());
return 0;
}
--
2.19.1
^ permalink raw reply related
* [PATCH v1 5/5] powerpc/pseries: Introduce dtl_entry tracepoint
From: Naveen N. Rao @ 2018-10-25 20:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Nathan Fontenot, Jeremy Kerr,
Steven Rostedt
Cc: linuxppc-dev
In-Reply-To: <cover.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
This tracepoint provides access to the fields of each DTL entry in the
Dispatch Trace Log buffer. Since the buffer is populated by the
hypervisor and since we allocate just a 4k area per cpu for the buffer,
we need to process the entries on a regular basis before they are
overwritten by the hypervisor. We do this by using a static branch (or a
reference counter if we don't have jump labels) in ret_from_except
similar to how the hcall/opal tracepoints do.
Apart from making the DTL entries available for processing through the
usual trace interface, this tracepoint also adds a new field 'distance'
to each DTL entry, enabling enhanced statistics around the vcpu dispatch
behavior of the hypervisor.
For Shared Processor LPARs, the POWER Hypervisor maintains a relatively
static mapping of LPAR vcpus to physical processor cores and tries to
always dispatch vcpus on their associated physical processor core. The
LPAR can discover this through the H_VPHN(flags=1) hcall to obtain the
associativity of the LPAR vcpus.
However, under certain scenarios, vcpus may be dispatched on a different
processor core. The actual physical processor number on which a certain
vcpu is dispatched is available to the LPAR in the 'processor_id' field
of each DTL entry. The LPAR can then discover the associativity of that
physical processor through the H_VPHN(flags=2) hcall. This can then be
compared to the home node associativity for that specific vcpu to
determine if the vcpu was dispatched on the same core or not. If the
vcpu was not dispatched on the home node, it is possible to determine if
the vcpu was dispatched in a different chip, socket or drawer.
The tracepoint field 'distance' encodes this information. If distance is
0, then the vcpu was dispatched on its home node/chip. If not,
increasing values of 'distance' indicate a dispatch on a different chip
in a MCM, different socket or a different drawer.
In terms of the implementation, we update our numa code to retain the
vcpu associativity that is retrieved while discovering our numa
topology. In addition, on tracepoint registration, we discover the
physical cpu associativity. This information is only retrieved during
the tracepoint registration and is not expected to change for the
duration of the trace.
To support configurations with/without CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
selected, we generalize and extend helpers for DTL buffer allocation,
freeing and registration. We also introduce a global variable 'dtl_mask'
to encode the DTL enable mask to be set for all cpus. This helps ensure
that cpus that come online honor the global enable mask.
Finally, to ensure that the new dtl_entry tracepoint usage does not
interfere with the dtl debugfs interface, we introduce helpers to ensure
only one of the two interfaces are used at any point in time.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/plpar_wrappers.h | 7 +
arch/powerpc/include/asm/trace.h | 55 +++++++
arch/powerpc/kernel/entry_64.S | 39 +++++
arch/powerpc/mm/numa.c | 144 ++++++++++++++++-
arch/powerpc/platforms/pseries/dtl.c | 10 +-
arch/powerpc/platforms/pseries/lpar.c | 187 +++++++++++++++++++++-
6 files changed, 434 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index 7dcbf42e9e11..029f019ddfb6 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -88,7 +88,14 @@ static inline long register_dtl(unsigned long cpu, unsigned long vpa)
return vpa_call(H_VPA_REG_DTL, cpu, vpa);
}
+extern void dtl_entry_tracepoint_enable(void);
+extern void dtl_entry_tracepoint_disable(void);
+extern int register_dtl_buffer_access(int global);
+extern void unregister_dtl_buffer_access(int global);
+extern void set_dtl_mask(u8 mask);
+extern void reset_dtl_mask(void);
extern void alloc_dtl_buffers(void);
+extern void free_dtl_buffers(void);
extern void register_dtl_buffer(int cpu);
extern void vpa_init(int cpu);
diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h
index d018e8602694..bcb8d66d3232 100644
--- a/arch/powerpc/include/asm/trace.h
+++ b/arch/powerpc/include/asm/trace.h
@@ -101,6 +101,61 @@ TRACE_EVENT_FN_COND(hcall_exit,
hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc
);
+
+#ifdef CONFIG_PPC_SPLPAR
+extern int dtl_entry_tracepoint_regfunc(void);
+extern void dtl_entry_tracepoint_unregfunc(void);
+extern u8 compute_dispatch_distance(unsigned int pcpu);
+
+TRACE_EVENT_FN(dtl_entry,
+
+ TP_PROTO(u8 dispatch_reason, u8 preempt_reason, u16 processor_id,
+ u32 enqueue_to_dispatch_time, u32 ready_to_enqueue_time,
+ u32 waiting_to_ready_time, u64 timebase, u64 fault_addr,
+ u64 srr0, u64 srr1),
+
+ TP_ARGS(dispatch_reason, preempt_reason, processor_id,
+ enqueue_to_dispatch_time, ready_to_enqueue_time,
+ waiting_to_ready_time, timebase, fault_addr,
+ srr0, srr1),
+
+ TP_STRUCT__entry(
+ __field(u8, dispatch_reason)
+ __field(u8, preempt_reason)
+ __field(u16, processor_id)
+ __field(u32, enqueue_to_dispatch_time)
+ __field(u32, ready_to_enqueue_time)
+ __field(u32, waiting_to_ready_time)
+ __field(u64, timebase)
+ __field(u64, fault_addr)
+ __field(u64, srr0)
+ __field(u64, srr1)
+ __field(u8, distance)
+ ),
+
+ TP_fast_assign(
+ __entry->dispatch_reason = dispatch_reason;
+ __entry->preempt_reason = preempt_reason;
+ __entry->processor_id = processor_id;
+ __entry->enqueue_to_dispatch_time = enqueue_to_dispatch_time;
+ __entry->ready_to_enqueue_time = ready_to_enqueue_time;
+ __entry->waiting_to_ready_time = waiting_to_ready_time;
+ __entry->timebase = timebase;
+ __entry->fault_addr = fault_addr;
+ __entry->srr0 = srr0;
+ __entry->srr1 = srr1;
+ __entry->distance = compute_dispatch_distance(processor_id);
+ ),
+
+ TP_printk("dispatch_reason=%u preempt_reason=%u processor_id=%u enq_to_disp=%u ready_to_enq=%u wait_to_ready=%u tb=%llu fault_addr=0x%llx srr0=0x%llx srr1=0x%llx distance=%u",
+ __entry->dispatch_reason, __entry->preempt_reason, __entry->processor_id,
+ __entry->enqueue_to_dispatch_time, __entry->ready_to_enqueue_time,
+ __entry->waiting_to_ready_time, __entry->timebase, __entry->fault_addr,
+ __entry->srr0, __entry->srr1, __entry->distance),
+
+ dtl_entry_tracepoint_regfunc, dtl_entry_tracepoint_unregfunc
+);
+#endif
#endif
#ifdef CONFIG_PPC_POWERNV
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 7b1693adff2a..9c3b922dda77 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -46,6 +46,7 @@
#include <asm/exception-64e.h>
#endif
#include <asm/feature-fixups.h>
+#include <linux/jump_label.h>
/*
* System calls.
@@ -714,6 +715,38 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
addi r1,r1,SWITCH_FRAME_SIZE
blr
+#if defined(CONFIG_TRACEPOINTS) && defined(CONFIG_PPC_SPLPAR)
+#ifdef HAVE_JUMP_LABEL
+#define TRACE_DTL_ENTRY_BRANCH(LABEL) \
+ ARCH_STATIC_BRANCH(LABEL, dtl_entry_tracepoint_key)
+#else
+
+ .pushsection ".toc","aw"
+ .globl dtl_entry_tracepoint_refcount
+dtl_entry_tracepoint_refcount:
+ .8byte 0
+ .popsection
+
+/*
+ * We branch around this in early init (eg when populating the MMU
+ * hashtable) by using an unconditional cpu feature.
+ */
+#define TRACE_DTL_ENTRY_BRANCH(LABEL) \
+BEGIN_FTR_SECTION; \
+ b 1f; \
+END_FTR_SECTION(0, 1); \
+ ld r12,dtl_entry_tracepoint_refcount@toc(r2); \
+ cmpdi r12,0; \
+ bne- LABEL; \
+1:
+#endif
+
+do_trace_dtl_entry:
+ bl __trace_dtl_entry
+ b .Lpost_trace_dtl_entry
+_ASM_NOKPROBE_SYMBOL(do_trace_dtl_entry);
+#endif
+
.align 7
_GLOBAL(ret_from_except)
ld r11,_TRAP(r1)
@@ -734,6 +767,11 @@ _GLOBAL(ret_from_except_lite)
mtmsrd r10,1 /* Update machine state */
#endif /* CONFIG_PPC_BOOK3E */
+#if defined(CONFIG_TRACEPOINTS) && defined(CONFIG_PPC_SPLPAR)
+ TRACE_DTL_ENTRY_BRANCH(do_trace_dtl_entry)
+.Lpost_trace_dtl_entry:
+#endif
+
CURRENT_THREAD_INFO(r9, r1)
ld r3,_MSR(r1)
#ifdef CONFIG_PPC_BOOK3E
@@ -768,6 +806,7 @@ _GLOBAL(ret_from_except_lite)
bl restore_math
b restore
#endif
+
1: andi. r0,r4,_TIF_NEED_RESCHED
beq 2f
bl restore_interrupts
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 693ae1c1acba..641fb12e9e55 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -41,6 +41,7 @@
#include <asm/setup.h>
#include <asm/vdso.h>
#include <asm/drmem.h>
+#include <asm/plpar_wrappers.h>
static int numa_enabled = 1;
@@ -1078,6 +1079,9 @@ static int prrn_enabled;
static void reset_topology_timer(void);
static int topology_timer_secs = 1;
static int topology_inited;
+static __be32 vcpu_associativity[NR_CPUS][VPHN_ASSOC_BUFSIZE];
+static __be32 pcpu_associativity[NR_CPUS][VPHN_ASSOC_BUFSIZE];
+static int no_distance_info;
/*
* Change polling interval for associativity changes.
@@ -1157,12 +1161,10 @@ static int update_cpu_associativity_changes_mask(void)
* Retrieve the new associativity information for a virtual processor's
* home node.
*/
-static long hcall_vphn(unsigned long cpu, __be32 *associativity)
+static long hcall_vphn(unsigned long hwcpu, unsigned long flags, __be32 *associativity)
{
long rc;
long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
- u64 flags = 1;
- int hwcpu = get_hard_smp_processor_id(cpu);
rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu);
vphn_unpack_associativity(retbuf, associativity);
@@ -1175,7 +1177,7 @@ static long vphn_get_associativity(unsigned long cpu,
{
long rc;
- rc = hcall_vphn(cpu, associativity);
+ rc = hcall_vphn(get_hard_smp_processor_id(cpu), 1, associativity);
switch (rc) {
case H_FUNCTION:
@@ -1200,7 +1202,7 @@ static long vphn_get_associativity(unsigned long cpu,
int find_and_online_cpu_nid(int cpu)
{
- __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
+ __be32 *associativity = vcpu_associativity[cpu];
int new_nid;
/* Use associativity from first thread for all siblings */
@@ -1237,6 +1239,138 @@ int find_and_online_cpu_nid(int cpu)
return new_nid;
}
+static unsigned int find_possible_pcpus(void)
+{
+ struct device_node *rtas;
+ unsigned int max_depth, num_pcpus = 0;
+
+ rtas = of_find_node_by_path("/rtas");
+ if (min_common_depth <= 0 || !rtas)
+ return 0;
+
+ if (!of_property_read_u32(rtas,
+ "ibm,max-associativity-domains",
+ &max_depth))
+ of_property_read_u32_index(rtas,
+ "ibm,max-associativity-domains",
+ max_depth, &num_pcpus);
+
+ of_node_put(rtas);
+
+ /*
+ * The OF property reports the maximum cpu number.
+ * We instead want the maximum number of cpus.
+ */
+ return num_pcpus + 1;
+}
+
+DECLARE_PER_CPU(u64, dtl_entry_ridx);
+
+/* This is only called on first registration */
+int dtl_entry_tracepoint_regfunc(void)
+{
+ unsigned int i, cpu, num_pcpus;
+ long rc;
+
+ if (register_dtl_buffer_access(1))
+ return -EBUSY;
+
+ if (!vphn_enabled || distance_ref_points_depth < 1 ||
+ !distance_ref_points ||
+ !firmware_has_feature(FW_FEATURE_TYPE1_AFFINITY))
+ no_distance_info = 1;
+ else {
+ no_distance_info = 0;
+ num_pcpus = find_possible_pcpus();
+ if (!num_pcpus)
+ num_pcpus = NR_CPUS;
+
+ /*
+ * Phyp numbers physical processors from 0 and theads per core
+ * remains the same across the hypervisor and the LPAR, so we can
+ * skip retrieving associativity for the sibling threads.
+ * NOTE: This is only retrieved during tracepoint registration
+ * and is not updated thereafter.
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ if (i != cpu_first_thread_sibling(i))
+ continue;
+ if (i >= num_pcpus) {
+ pcpu_associativity[i][0] = cpu_to_be32(NR_CPUS);
+ continue;
+ }
+ rc = hcall_vphn(i, 2, pcpu_associativity[i]);
+ if (rc != H_SUCCESS) {
+ pcpu_associativity[i][0] = cpu_to_be32(NR_CPUS);
+ pr_debug_ratelimited("pcpu_associativity could not be discovered for cpu %d\n", i);
+ }
+ }
+ }
+
+ set_dtl_mask(DTL_LOG_ALL);
+
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ /* Setup dtl buffers and register those */
+ alloc_dtl_buffers();
+
+ for_each_online_cpu(cpu)
+ register_dtl_buffer(cpu);
+#endif
+
+ for_each_online_cpu(cpu)
+ per_cpu(dtl_entry_ridx, cpu) = be64_to_cpu(lppaca_of(cpu).dtl_idx);
+
+ dtl_entry_tracepoint_enable();
+
+ return 0;
+}
+
+void dtl_entry_tracepoint_unregfunc(void)
+{
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ int cpu;
+#endif
+
+ dtl_entry_tracepoint_disable();
+
+ reset_dtl_mask();
+
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ for_each_possible_cpu(cpu)
+ unregister_dtl(get_hard_smp_processor_id(cpu));
+
+ free_dtl_buffers();
+#endif
+
+ unregister_dtl_buffer_access(1);
+}
+
+/* We return 255 to indicate that we couldn't determine the dispatch distance */
+u8 compute_dispatch_distance(unsigned int pcpu)
+{
+ __be32 *pcpu_assoc, *vcpu_assoc;
+ int i, index, distance = distance_ref_points_depth;
+
+ if (!vphn_enabled || no_distance_info)
+ return 255;
+
+ vcpu_assoc = vcpu_associativity[cpu_first_thread_sibling(smp_processor_id())];
+ pcpu_assoc = pcpu_associativity[cpu_first_thread_sibling(pcpu)];
+
+ if (be32_to_cpu(pcpu_assoc[0]) == NR_CPUS)
+ return 255;
+
+ for (i = distance_ref_points_depth - 1; i >= 0; i--) {
+ index = be32_to_cpu(distance_ref_points[i]);
+ if (be32_to_cpu(vcpu_assoc[index]) == be32_to_cpu(pcpu_assoc[index]))
+ distance--;
+ else
+ break;
+ }
+
+ return distance;
+}
+
/*
* Update the CPU maps and sysfs entries for a single CPU when its NUMA
* characteristics change. This function doesn't perform any locking and is
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
index fb05804adb2f..ec25d3e6cdbb 100644
--- a/arch/powerpc/platforms/pseries/dtl.c
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -193,11 +193,15 @@ static int dtl_enable(struct dtl *dtl)
if (dtl->buf)
return -EBUSY;
+ if (register_dtl_buffer_access(0))
+ return -EBUSY;
+
n_entries = dtl_buf_entries;
buf = kmem_cache_alloc_node(dtl_cache, GFP_KERNEL, cpu_to_node(dtl->cpu));
if (!buf) {
printk(KERN_WARNING "%s: buffer alloc failed for cpu %d\n",
__func__, dtl->cpu);
+ unregister_dtl_buffer_access(0);
return -ENOMEM;
}
@@ -214,8 +218,11 @@ static int dtl_enable(struct dtl *dtl)
}
spin_unlock(&dtl->lock);
- if (rc)
+ if (rc) {
+ unregister_dtl_buffer_access(0);
kmem_cache_free(dtl_cache, buf);
+ }
+
return rc;
}
@@ -227,6 +234,7 @@ static void dtl_disable(struct dtl *dtl)
dtl->buf = NULL;
dtl->buf_entries = 0;
spin_unlock(&dtl->lock);
+ unregister_dtl_buffer_access(0);
}
/* file interface */
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index d83bb3db6767..67b2c59c10b1 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -30,6 +30,7 @@
#include <linux/jump_label.h>
#include <linux/delay.h>
#include <linux/stop_machine.h>
+#include <linux/spinlock.h>
#include <asm/processor.h>
#include <asm/mmu.h>
#include <asm/page.h>
@@ -64,6 +65,167 @@ EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall9);
EXPORT_SYMBOL(plpar_hcall_norets);
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+u8 dtl_mask = DTL_LOG_PREEMPT;
+#else
+u8 dtl_mask = 0;
+#endif
+
+static DEFINE_SPINLOCK(dtl_buffer_refctr_lock);
+static unsigned int dtl_buffer_global_refctr, dtl_buffer_percpu_refctr;
+
+int register_dtl_buffer_access(int global)
+{
+ int rc = 0;
+
+ spin_lock(&dtl_buffer_refctr_lock);
+
+ if ((global && (dtl_buffer_global_refctr || dtl_buffer_percpu_refctr)) ||
+ (!global && dtl_buffer_global_refctr)) {
+ rc = -1;
+ } else {
+ if (global)
+ dtl_buffer_global_refctr++;
+ else
+ dtl_buffer_percpu_refctr++;
+ }
+
+ spin_unlock(&dtl_buffer_refctr_lock);
+
+ return rc;
+}
+
+void unregister_dtl_buffer_access(int global)
+{
+ spin_lock(&dtl_buffer_refctr_lock);
+
+ if (global)
+ dtl_buffer_global_refctr--;
+ else
+ dtl_buffer_percpu_refctr--;
+
+ spin_unlock(&dtl_buffer_refctr_lock);
+}
+
+void set_dtl_mask(u8 mask)
+{
+ int cpu;
+
+ dtl_mask = mask;
+ for_each_present_cpu(cpu)
+ lppaca_of(cpu).dtl_enable_mask = dtl_mask;
+}
+
+void reset_dtl_mask()
+{
+ int cpu;
+
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ dtl_mask = DTL_LOG_PREEMPT;
+#else
+ dtl_mask = 0;
+#endif
+ for_each_present_cpu(cpu)
+ lppaca_of(cpu).dtl_enable_mask = dtl_mask;
+}
+
+#if defined(CONFIG_TRACEPOINTS) && defined(CONFIG_PPC_SPLPAR)
+#ifdef HAVE_JUMP_LABEL
+struct static_key dtl_entry_tracepoint_key = STATIC_KEY_INIT;
+
+void dtl_entry_tracepoint_enable(void)
+{
+ static_key_slow_inc(&dtl_entry_tracepoint_key);
+}
+
+void dtl_entry_tracepoint_disable(void)
+{
+ static_key_slow_dec(&dtl_entry_tracepoint_key);
+}
+#else
+/* NB: reg/unreg are called while guarded with the tracepoints_mutex */
+extern long dtl_entry_tracepoint_refcount;
+
+void dtl_entry_tracepoint_enable(void)
+{
+ dtl_entry_tracepoint_refcount++;
+}
+
+void dtl_entry_tracepoint_disable(void)
+{
+ dtl_entry_tracepoint_refcount--;
+}
+#endif
+
+/*
+ * Since the tracing code might execute hcalls we need to guard against
+ * recursion. One example of this are spinlocks calling H_YIELD on
+ * shared processor partitions.
+ */
+static DEFINE_PER_CPU(unsigned int, dtl_entry_trace_depth);
+DEFINE_PER_CPU(u64, dtl_entry_ridx);
+
+static void __process_dtl_buffer(void)
+{
+ struct dtl_entry dtle;
+ u64 i = __this_cpu_read(dtl_entry_ridx);
+ struct dtl_entry *dtl = local_paca->dispatch_log + (i % N_DISPATCH_LOG);
+ struct dtl_entry *dtl_end = local_paca->dispatch_log_end;
+ struct lppaca *vpa = local_paca->lppaca_ptr;
+
+ if (!dtl || i == be64_to_cpu(vpa->dtl_idx))
+ return;
+
+ while (i < be64_to_cpu(vpa->dtl_idx)) {
+ dtle = *dtl;
+ barrier();
+ if (i + N_DISPATCH_LOG < be64_to_cpu(vpa->dtl_idx)) {
+ /* buffer has overflowed */
+ i = be64_to_cpu(vpa->dtl_idx) - N_DISPATCH_LOG;
+ dtl = local_paca->dispatch_log + (i % N_DISPATCH_LOG);
+ continue;
+ }
+ trace_dtl_entry(dtle.dispatch_reason, dtle.preempt_reason,
+ be16_to_cpu(dtle.processor_id),
+ be32_to_cpu(dtle.enqueue_to_dispatch_time),
+ be32_to_cpu(dtle.ready_to_enqueue_time),
+ be32_to_cpu(dtle.waiting_to_ready_time),
+ be64_to_cpu(dtle.timebase),
+ be64_to_cpu(dtle.fault_addr),
+ be64_to_cpu(dtle.srr0),
+ be64_to_cpu(dtle.srr1));
+ ++i;
+ ++dtl;
+ if (dtl == dtl_end)
+ dtl = local_paca->dispatch_log;
+ }
+
+ __this_cpu_write(dtl_entry_ridx, i);
+}
+
+void __trace_dtl_entry(void)
+{
+ unsigned long flags;
+ unsigned int *depth;
+
+ local_irq_save(flags);
+ preempt_disable();
+
+ depth = this_cpu_ptr(&dtl_entry_trace_depth);
+
+ if (*depth)
+ goto out;
+
+ (*depth)++;
+ __process_dtl_buffer();
+ (*depth)--;
+
+out:
+ preempt_enable();
+ local_irq_restore(flags);
+}
+#endif
+
void alloc_dtl_buffers(void)
{
int cpu;
@@ -72,11 +234,15 @@ void alloc_dtl_buffers(void)
for_each_possible_cpu(cpu) {
pp = paca_ptrs[cpu];
+ if (pp->dispatch_log)
+ continue;
dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
pr_warn("Stolen time statistics will be unreliable\n");
+#endif
break;
}
@@ -87,6 +253,23 @@ void alloc_dtl_buffers(void)
}
}
+void free_dtl_buffers(void)
+{
+ int cpu;
+ struct paca_struct *pp;
+
+ for_each_possible_cpu(cpu) {
+ pp = paca_ptrs[cpu];
+ if (!pp->dispatch_log)
+ continue;
+ kmem_cache_free(dtl_cache, pp->dispatch_log);
+ pp->dtl_ridx = 0;
+ pp->dispatch_log = 0;
+ pp->dispatch_log_end = 0;
+ pp->dtl_curr = 0;
+ }
+}
+
void register_dtl_buffer(int cpu)
{
long ret;
@@ -96,7 +279,7 @@ void register_dtl_buffer(int cpu)
pp = paca_ptrs[cpu];
dtl = pp->dispatch_log;
- if (dtl) {
+ if (dtl && dtl_mask) {
pp->dtl_ridx = 0;
pp->dtl_curr = dtl;
lppaca_of(cpu).dtl_idx = 0;
@@ -107,7 +290,7 @@ void register_dtl_buffer(int cpu)
if (ret)
pr_err("WARNING: DTL registration of cpu %d (hw %d) "
"failed with %ld\n", cpu, hwcpu, ret);
- lppaca_of(cpu).dtl_enable_mask = DTL_LOG_PREEMPT;
+ lppaca_of(cpu).dtl_enable_mask = dtl_mask;
}
}
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
From: Rob Herring @ 2018-10-25 21:13 UTC (permalink / raw)
To: rppt
Cc: Linux-MIPS, linux-ia64, SH-Linux, Catalin Marinas, Will Deacon,
devicetree, sparclinux, linux-riscv,
open list:GENERIC INCLUDE/ASM HEADER FILES, linux-s390,
Florian Fainelli, linux-c6x-dev, linux-hexagon, arcml,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
Marc Zyngier, linux-um, linux-m68k, Openrisc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-parisc, Ard Biesheuvel, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, linux-alpha, Olof Johansson,
nios2-dev, linuxppc-dev
In-Reply-To: <20181025172935.GA27364@rapoport-lnx>
On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> > +Ard
> >
> > On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > >
> > > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > > because we define __early_init_dt_declare_initrd() differently and we do
> > > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > > amount of other header files, and translation units as well.
> > > >
> > > > I scratch my head sometimes as to why some config options rebuild so
> > > > much stuff. One down, ? to go. :)
> > > >
> > > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > > > systems that generate two kernels: one with the initramfs and one
> > > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > > another one that does this.
> > > > >
> > > > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > > > custom __early_init_dt_declare_initrd() definition away from
> > > > > asm/memory.h
> > > > >
> > > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > > factor 73 approximately.
> > > > >
> > > > > Apologies for the long CC list, please let me know how you would go
> > > > > about merging that and if another approach would be preferable, e.g:
> > > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > > something like that.
> > > >
> > > > There may be a better way as of 4.20 because bootmem is now gone and
> > > > only memblock is used. This should unify what each arch needs to do
> > > > with initrd early. We need the physical address early for memblock
> > > > reserving. Then later on we need the virtual address to access the
> > > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > > physical addresses (or add 2 new variables would be less invasive and
> > > > allow for different translation than __va()). The sanity checks and
> > > > memblock reserve could also perhaps be moved to a common location.
> > > >
> > > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > > it like the above option.
> > >
> > > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > > Something like this might be just all we need (completely untested,
> > > probably it won't even compile):
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 9d9582c..e9ca238 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > > phys_addr_t arm64_dma_phys_limit __ro_after_init;
> > >
> > > #ifdef CONFIG_BLK_DEV_INITRD
> > > +
> > > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > > +
> > > static int __init early_initrd(char *p)
> > > {
> > > unsigned long start, size;
> > > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > > if (*endp == ',') {
> > > size = memparse(endp + 1, NULL);
> > >
> > > - initrd_start = start;
> > > - initrd_end = start + size;
> > > + initrd_start_phys = start;
> > > + initrd_end_phys = end;
> > > }
> > > return 0;
> > > }
> > > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > > memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> > > }
> > >
> > > - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> > > + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> > > + (initrd_start || initrd_start_phys)) {
> > > + /*
> > > + * FIXME: ensure proper precendence between
> > > + * early_initrd and DT when both are present
> >
> > Command line takes precedence, so just reverse the order.
> >
> > > + */
> > > + if (initrd_start) {
> > > + initrd_start_phys = __phys_to_virt(initrd_start);
> > > + initrd_end_phys = __phys_to_virt(initrd_end);
BTW, I think you meant virt_to_phys() here?
> >
> > AIUI, the original issue was doing the P2V translation was happening
> > too early and the VA could be wrong if the linear range is adjusted.
> > So I don't think this would work.
>
> Probably things have changed since then, but in the current code there is
>
> initrd_start = __phys_to_virt(initrd_start);
>
> and in between only the code related to CONFIG_RANDOMIZE_BASE, so I believe
> it's safe to use __phys_to_virt() here as well.
Here is fine yes, but I believe it was the the phys to virt in the DT
code before adjusting the linear range that was the problem.
Rob
^ permalink raw reply
* Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support
From: Rob Herring @ 2018-10-25 21:52 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, devicetree,
gregkh, kstewart, niklas.cassel, linux-pci, linux-kernel, kishon,
minghuan.Lian, cyrille.pitchen, linux-arm-kernel, pombredanne,
bhelgaas, leoyang.li, shawnguo, shawn.lin, mingkai.hu,
linuxppc-dev
In-Reply-To: <20181025110901.5680-3-xiaowei.bao@nxp.com>
On Thu, Oct 25, 2018 at 07:08:58PM +0800, Xiaowei Bao wrote:
> Add the EP mode support.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> .../devicetree/bindings/pci/layerscape-pci.txt | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 66df1e8..d3d7be1 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -13,12 +13,15 @@ information.
>
> Required properties:
> - compatible: should contain the platform identifier such as:
> + RC mode:
> "fsl,ls1021a-pcie", "snps,dw-pcie"
> "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
> "fsl,ls2088a-pcie"
> "fsl,ls1088a-pcie"
> "fsl,ls1046a-pcie"
> "fsl,ls1012a-pcie"
> + EP mode:
> + "fsl,ls-pcie-ep"
You need SoC specific compatibles for the same reasons as the RC.
Rob
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Relax L1d miss targets for rfi_flush test
From: Joel Stanley @ 2018-10-25 22:07 UTC (permalink / raw)
To: naveen.n.rao; +Cc: linuxppc-dev
In-Reply-To: <20181023080456.2558-1-naveen.n.rao@linux.vnet.ibm.com>
On Tue, 23 Oct 2018 at 18:35, Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> When running the rfi_flush test, if the system is loaded, we see two
> issues:
> 1. The L1d misses when rfi_flush is disabled increase significantly due
> to other workloads interfering with the cache.
> 2. The L1d misses when rfi_flush is enabled sometimes goes slightly
> below the expected number of misses.
>
> To address these, let's relax the expected number of L1d misses:
> 1. When rfi_flush is disabled, we allow upto half the expected number of
> the misses for when rfi_flush is enabled.
> 2. When rfi_flush is enabled, we allow ~1% lower number of cache misses.
>
> Reported-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Thanks, this now passes 10/10 runs on my Romulus machine. A log is
attached below.
Tested-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
---
for i in `seq 1 10`; do sudo ./rfi_flush; done
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 5013939 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195054696 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 11015957 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195053292 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 8017248 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195145579 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 11015308 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195042376 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 1021356 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195031624 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 6015342 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195037322 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 16635 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195032476 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 6013599 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195060037 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 25236 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195052859 > 190000000) [10/10 pass]
success: rfi_flush_test
test: rfi_flush_test
tags: git_version:next-20181018-67-g61f7abf00719
PASS (L1D misses with rfi_flush=0: 18120 < 95000000) [10/10 pass]
PASS (L1D misses with rfi_flush=1: 195014212 > 190000000) [10/10 pass]
success: rfi_flush_test
^ permalink raw reply
* Re: [PATCH v1 3/5] powerpc/pseries: Fix stolen time accounting when dtl debugfs is used
From: Paul Mackerras @ 2018-10-25 21:08 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev, Jeremy Kerr, Steven Rostedt, Nathan Fontenot
In-Reply-To: <16929569199445cd09d9142505b2349620328b38.1540488386.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Oct 26, 2018 at 01:55:44AM +0530, Naveen N. Rao wrote:
> When the dtl debugfs interface is used, we usually set the
> dtl_enable_mask to 0x7 (DTL_LOG_ALL). When this happens, we start seeing
> DTL entries for all preempt reasons, including CEDE. In
> scan_dispatch_log(), we add up the times from all entries and account
> those towards stolen time. However, we should only be accounting stolen
> time when the preemption was due to HDEC at the end of our time slice.
It's always been the case that stolen time when idle has been
accounted as idle time, not stolen time. That's why we didn't check
for this in the past.
Do you have a test that shows different results (as in reported idle
and stolen times) with this patch compared to without?
Paul.
^ permalink raw reply
* Re: [PATCH] seccomp: Add pkru into seccomp_data
From: Andy Lutomirski @ 2018-10-25 23:00 UTC (permalink / raw)
To: Michael Sammler
Cc: Florian Weimer, Will Drewry, Kees Cook, Linux API, linuxram,
linuxppc-dev
In-Reply-To: <c4d3f5c1-a2dc-5b44-4d12-1fae829a372c@mpi-sws.org>
On Thu, Oct 25, 2018 at 9:42 AM Michael Sammler <msammler@mpi-sws.org> wrote:
>
> On 10/25/2018 11:12 AM, Florian Weimer wrote:
> >> I understand your concern about exposing the number of protection keys
> >> in the ABI. One idea would be to state, that the pkru field (which
> >> should probably be renamed) contains an architecture specific value,
> >> which could then be the PKRU on x86 and AMR (or another register) on
> >> POWER. This new field should probably be extended to __u64 and the
> >> reserved field removed.
> > POWER also has proper read/write bit separation, not PKEY_DISABLE_ACCESS
> > (disable read and write) and PKEY_DISABLE_WRITE like Intel. It's
> > currently translated by the kernel, but I really need a
> > PKEY_DISABLE_READ bit in glibc to implement pkey_get in case the memory
> > is write-only.
> The idea here would be to simply provide the raw value of the register
> (PKRU on x86, AMR on POWER) to the BPF program and let the BPF program
> (or maybe a higher level library like libseccomp) deal with the
> complications of interpreting this architecture specific value (similar
> how the BPF program currently already has to deal with architecture
> specific system call numbers). If an architecture were to support more
> protection keys than fit into the field, the architecture specific value
> stored in the field might simply be the first protection keys. If there
> was interest, it would be possible to add more architecture specific
> fields to seccomp_data.
> >> Another idea would be to not add a field in the seccomp_data
> >> structure, but instead provide a new BPF instruction, which reads the
> >> value of a specified protection key.
> > I would prefer that if it's possible. We should make sure that the bits
> > are the same as those returned from pkey_get. I have an implementation
> > on POWER, but have yet to figure out the implications for 32-bit because
> > I do not know the AMR register size there.
> >
> > Thanks,
> > Florian
> I have had a look at how BPF is implemented and it does not seem to be
> easy to just add an BPF instruction for seccomp since (as far as I
> understand) the code of the classical BPF (as used by seccomp) is shared
> with the code of eBPF, which is used in many parts of the kernel and
> there is at least one interpreter and one JIT compiler for BPF. But
> maybe someone with more experience than me can comment on how hard it
> would be to add an instruction to BPF.
>
You could bite the bullet and add seccomp eBPF support :)
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
From: Florian Fainelli @ 2018-10-25 23:07 UTC (permalink / raw)
To: Rob Herring, rppt
Cc: Linux-MIPS, linux-ia64, SH-Linux, Catalin Marinas, Will Deacon,
devicetree, sparclinux, linux-riscv,
open list:GENERIC INCLUDE/ASM HEADER FILES, linux-s390,
linux-c6x-dev, linux-hexagon, arcml,
moderated list:H8/300 ARCHITECTURE, linux-xtensa, Arnd Bergmann,
Marc Zyngier, linux-um, linux-m68k, Openrisc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-parisc, Ard Biesheuvel, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, linux-alpha, Olof Johansson,
nios2-dev, linuxppc-dev
In-Reply-To: <CAL_JsqJrMq+QHvuOsqEdCFchmXsd4s2XKUD_TboKzeEQprJvjg@mail.gmail.com>
On 10/25/18 2:13 PM, Rob Herring wrote:
> On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>>
>> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
>>> +Ard
>>>
>>> On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
>>>>
>>>> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
>>>>> On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> While investigating why ARM64 required a ton of objects to be rebuilt
>>>>>> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
>>>>>> because we define __early_init_dt_declare_initrd() differently and we do
>>>>>> that in arch/arm64/include/asm/memory.h which gets included by a fair
>>>>>> amount of other header files, and translation units as well.
>>>>>
>>>>> I scratch my head sometimes as to why some config options rebuild so
>>>>> much stuff. One down, ? to go. :)
>>>>>
>>>>>> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
>>>>>> systems that generate two kernels: one with the initramfs and one
>>>>>> without. buildroot is one of these build systems, OpenWrt is also
>>>>>> another one that does this.
>>>>>>
>>>>>> This patch series proposes adding an empty initrd.h to satisfy the need
>>>>>> for drivers/of/fdt.c to unconditionally include that file, and moves the
>>>>>> custom __early_init_dt_declare_initrd() definition away from
>>>>>> asm/memory.h
>>>>>>
>>>>>> This cuts the number of objects rebuilds from 1920 down to 26, so a
>>>>>> factor 73 approximately.
>>>>>>
>>>>>> Apologies for the long CC list, please let me know how you would go
>>>>>> about merging that and if another approach would be preferable, e.g:
>>>>>> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
>>>>>> something like that.
>>>>>
>>>>> There may be a better way as of 4.20 because bootmem is now gone and
>>>>> only memblock is used. This should unify what each arch needs to do
>>>>> with initrd early. We need the physical address early for memblock
>>>>> reserving. Then later on we need the virtual address to access the
>>>>> initrd. Perhaps we should just change initrd_start and initrd_end to
>>>>> physical addresses (or add 2 new variables would be less invasive and
>>>>> allow for different translation than __va()). The sanity checks and
>>>>> memblock reserve could also perhaps be moved to a common location.
>>>>>
>>>>> Alternatively, given arm64 is the only oddball, I'd be fine with an
>>>>> "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
>>>>> __early_init_dt_declare_initrd as long as we have a path to removing
>>>>> it like the above option.
>>>>
>>>> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
>>>> Something like this might be just all we need (completely untested,
>>>> probably it won't even compile):
>>>>
>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>> index 9d9582c..e9ca238 100644
>>>> --- a/arch/arm64/mm/init.c
>>>> +++ b/arch/arm64/mm/init.c
>>>> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
>>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>>
>>>> #ifdef CONFIG_BLK_DEV_INITRD
>>>> +
>>>> +static phys_addr_t initrd_start_phys, initrd_end_phys;
>>>> +
>>>> static int __init early_initrd(char *p)
>>>> {
>>>> unsigned long start, size;
>>>> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
>>>> if (*endp == ',') {
>>>> size = memparse(endp + 1, NULL);
>>>>
>>>> - initrd_start = start;
>>>> - initrd_end = start + size;
>>>> + initrd_start_phys = start;
>>>> + initrd_end_phys = end;
>>>> }
>>>> return 0;
>>>> }
>>>> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
>>>> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
>>>> }
>>>>
>>>> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
>>>> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
>>>> + (initrd_start || initrd_start_phys)) {
>>>> + /*
>>>> + * FIXME: ensure proper precendence between
>>>> + * early_initrd and DT when both are present
>>>
>>> Command line takes precedence, so just reverse the order.
>>>
>>>> + */
>>>> + if (initrd_start) {
>>>> + initrd_start_phys = __phys_to_virt(initrd_start);
>>>> + initrd_end_phys = __phys_to_virt(initrd_end);
>
> BTW, I think you meant virt_to_phys() here?
>
>>>
>>> AIUI, the original issue was doing the P2V translation was happening
>>> too early and the VA could be wrong if the linear range is adjusted.
>>> So I don't think this would work.
>>
>> Probably things have changed since then, but in the current code there is
>>
>> initrd_start = __phys_to_virt(initrd_start);
>>
>> and in between only the code related to CONFIG_RANDOMIZE_BASE, so I believe
>> it's safe to use __phys_to_virt() here as well.
>
> Here is fine yes, but I believe it was the the phys to virt in the DT
> code before adjusting the linear range that was the problem.
FWIW, I am extracting the ARM implementation that parses the initrd
early command line parameter and the "setup" code doing the page
boundary alignment and memblock checking into a helper into lib/ that
other architectures can re-use. So far, this removes the need for
unicore32, arc and arm to duplicate essentially the same logic.
--
Florian
^ permalink raw reply
* Re: [PATCH] seccomp: Add pkru into seccomp_data
From: Kees Cook @ 2018-10-26 0:35 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Florian Weimer, Will Drewry, Linux API, linuxram, Michael Sammler,
linuxppc-dev
In-Reply-To: <CALCETrX_E5_p1-MjCcdtRQbziCCzXcOCfxRBckZx_zbO1QX=Dw@mail.gmail.com>
On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> You could bite the bullet and add seccomp eBPF support :)
I'm not convinced this is a good enough reason for gaining the eBPF
attack surface yet.
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] seccomp: Add pkru into seccomp_data
From: Andy Lutomirski @ 2018-10-26 0:49 UTC (permalink / raw)
To: Kees Cook
Cc: Florian Weimer, Will Drewry, Linux API, linuxram, Michael Sammler,
linuxppc-dev
In-Reply-To: <CAGXu5jLE2VBqo_rkBJ+BJkp1==WLLg=N=-3gjTCCjcN1=bodSg@mail.gmail.com>
> On Oct 25, 2018, at 5:35 PM, Kees Cook <keescook@chromium.org> wrote:
>
>> On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> You could bite the bullet and add seccomp eBPF support :)
>
> I'm not convinced this is a good enough reason for gaining the eBPF
> attack surface yet.
>
>
Is it an interesting attack surface? It’s certainly scarier if you’re worried about attacks from the sandbox creator, but the security inside the sandbox should be more or less equivalent, no?
^ permalink raw reply
* RE: [PATCH 3/6] PCI: layerscape: Add the EP mode support
From: Xiaowei Bao @ 2018-10-26 3:45 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, kstewart@linuxfoundation.org,
niklas.cassel@axis.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
cyrille.pitchen@free-electrons.com,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20181025215246.GA14861@bogus>
-----Original Message-----
From: Rob Herring <robh@kernel.org>
Sent: 2018年10月26日 5:53
To: Xiaowei Bao <xiaowei.bao@nxp.com>
Cc: bhelgaas@google.com; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org; cyrille.pitchen@free-electrons.com; pombredanne@nexb.com; shawn.lin@rock-chips.com; niklas.cassel@axis.com; linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/6] PCI: layerscape: Add the EP mode support
On Thu, Oct 25, 2018 at 07:08:58PM +0800, Xiaowei Bao wrote:
> Add the EP mode support.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> .../devicetree/bindings/pci/layerscape-pci.txt | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 66df1e8..d3d7be1 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -13,12 +13,15 @@ information.
>
> Required properties:
> - compatible: should contain the platform identifier such as:
> + RC mode:
> "fsl,ls1021a-pcie", "snps,dw-pcie"
> "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
> "fsl,ls2088a-pcie"
> "fsl,ls1088a-pcie"
> "fsl,ls1046a-pcie"
> "fsl,ls1012a-pcie"
> + EP mode:
> + "fsl,ls-pcie-ep"
You need SoC specific compatibles for the same reasons as the RC.
[Xiaowei Bao] I want to contains all layerscape platform use one compatible if the PCIe controller work in EP mode.
Rob
^ 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