* [PATCH v3 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
From: Leonardo Bras @ 2021-04-08 20:19 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Leonardo Bras, Alexey Kardashevskiy, brking
Cc: linuxppc-dev, linux-kernel
According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
will let the OS know all possible pagesizes that can be used for creating a
new DDW.
Currently Linux will only try using 3 of the 8 available options:
4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M,
128M, 256M and 16G.
Enabling bigger pages would be interesting for direct mapping systems
with a lot of RAM, while using less TCE entries.
Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
---
Changes since v2:
- Restore 'int array & shift' strategy
- Remove defines for RTAS "IO Page Size" output of ibm,query-pe-dma-window
- Added/Improved comments
Link: http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210407195613.131140-1-leobras.c@gmail.com/
Changes since v1:
- Remove page shift defines, replace by __builtin_ctzll(SZ_XXX)
- Add bit field defines for RTAS "IO Page Shift" output of ibm,query-pe-dma-window
- Use struct array instead of int array to be more explicit on pagesizes
Link: http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210322190943.715368-1-leobras.c@gmail.com/
arch/powerpc/platforms/pseries/iommu.c | 37 +++++++++++++++++++++-----
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 9fc5217f0c8e..67c9953a6503 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1099,6 +1099,33 @@ static void reset_dma_window(struct pci_dev *dev, struct device_node *par_dn)
ret);
}
+/* Return largest page shift based on "IO Page Sizes" output of ibm,query-pe-dma-window. */
+static int iommu_get_page_shift(u32 query_page_size)
+{
+ /* Supported IO page-sizes according to LoPAR */
+ const int shift[] = {
+ __builtin_ctzll(SZ_4K), __builtin_ctzll(SZ_64K), __builtin_ctzll(SZ_16M),
+ __builtin_ctzll(SZ_32M), __builtin_ctzll(SZ_64M), __builtin_ctzll(SZ_128M),
+ __builtin_ctzll(SZ_256M), __builtin_ctzll(SZ_16G)
+ };
+
+ int i = ARRAY_SIZE(shift) - 1;
+
+ /*
+ * On LoPAR, ibm,query-pe-dma-window outputs "IO Page Sizes" using a bit field:
+ * - bit 31 means 4k pages are supported,
+ * - bit 30 means 64k pages are supported, and so on.
+ * Larger pagesizes map more memory with the same amount of TCEs, so start probing them.
+ */
+ for (; i >= 0 ; i--) {
+ if (query_page_size & (1 << i))
+ return shift[i];
+ }
+
+ /* No valid page size found. */
+ return 0;
+}
+
/*
* If the PE supports dynamic dma windows, and there is space for a table
* that can map all pages in a linear offset, then setup such a table,
@@ -1206,13 +1233,9 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
goto out_failed;
}
}
- if (query.page_size & 4) {
- page_shift = 24; /* 16MB */
- } else if (query.page_size & 2) {
- page_shift = 16; /* 64kB */
- } else if (query.page_size & 1) {
- page_shift = 12; /* 4kB */
- } else {
+
+ page_shift = iommu_get_page_shift(query.page_size);
+ if (!page_shift) {
dev_dbg(&dev->dev, "no supported direct page size in mask %x",
query.page_size);
goto out_failed;
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v7] soc: fsl: enable acpi support in RCPM driver
From: Li Yang @ 2021-04-08 21:33 UTC (permalink / raw)
To: Ran Wang
Cc: Peng Ma, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, lkml
In-Reply-To: <20210408030353.37193-1-ran.wang_1@nxp.com>
On Wed, Apr 7, 2021 at 9:58 PM Ran Wang <ran.wang_1@nxp.com> wrote:
>
> From: Peng Ma <peng.ma@nxp.com>
>
> This patch enables ACPI support in RCPM driver.
>
> Signed-off-by: Peng Ma <peng.ma@nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Applied for next. Thanks.
> ---
> Change in v7:
> - Update comment for checking RCPM node which refferred to
>
> Change in v6:
> - Remove copyright udpate to rebase on latest mainline
>
> Change in v5:
> - Fix panic when dev->of_node is null
>
> Change in v4:
> - Make commit subject more accurate
> - Remove unrelated new blank line
>
> Change in v3:
> - Add #ifdef CONFIG_ACPI for acpi_device_id
> - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
>
> Change in v2:
> - Update acpi_device_id to fix conflict with other driver
>
> drivers/soc/fsl/rcpm.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
> index 4ace28cab314..90d3f4060b0c 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -13,6 +13,7 @@
> #include <linux/slab.h>
> #include <linux/suspend.h>
> #include <linux/kernel.h>
> +#include <linux/acpi.h>
>
> #define RCPM_WAKEUP_CELL_MAX_SIZE 7
>
> @@ -78,10 +79,20 @@ static int rcpm_pm_prepare(struct device *dev)
> "fsl,rcpm-wakeup", value,
> rcpm->wakeup_cells + 1);
>
> - /* Wakeup source should refer to current rcpm device */
> - if (ret || (np->phandle != value[0]))
> + if (ret)
> continue;
>
> + /*
> + * For DT mode, would handle devices with "fsl,rcpm-wakeup"
> + * pointing to the current RCPM node.
> + *
> + * For ACPI mode, currently we assume there is only one
> + * RCPM controller existing.
> + */
> + if (is_of_node(dev->fwnode))
> + if (np->phandle != value[0])
> + continue;
> +
> /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
> * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
> * of wakeup source IP contains an integer array: <phandle to
> @@ -172,10 +183,19 @@ static const struct of_device_id rcpm_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, rcpm_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id rcpm_acpi_ids[] = {
> + {"NXP0015",},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
> +#endif
> +
> static struct platform_driver rcpm_driver = {
> .driver = {
> .name = "rcpm",
> .of_match_table = rcpm_of_match,
> + .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> .pm = &rcpm_pm_ops,
> },
> .probe = rcpm_probe,
> --
> 2.25.1
>
^ permalink raw reply
* [powerpc:next-test 168/182] include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
From: kernel test robot @ 2021-04-09 0:41 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4258 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb
commit: 093cb12967d4bde01a4170fd342bc0d443004599 [168/182] powerpc/32s: Define a MODULE area below kernel text all the time
config: powerpc64-randconfig-c004-20210408 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=093cb12967d4bde01a4170fd342bc0d443004599
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 093cb12967d4bde01a4170fd342bc0d443004599
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from <command-line>:
arch/powerpc/kernel/module.c: In function 'module_alloc':
>> include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert'
301 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert'
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
arch/powerpc/kernel/module.c:105:2: note: in expansion of macro 'BUILD_BUG_ON'
105 | BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
| ^~~~~~~~~~~~
vim +/__compiletime_assert_171 +320 include/linux/compiler_types.h
eb5c2d4b45e3d2 Will Deacon 2020-07-21 306
eb5c2d4b45e3d2 Will Deacon 2020-07-21 307 #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 308 __compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 309
eb5c2d4b45e3d2 Will Deacon 2020-07-21 310 /**
eb5c2d4b45e3d2 Will Deacon 2020-07-21 311 * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 312 * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2 Will Deacon 2020-07-21 313 * @msg: a message to emit if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 314 *
eb5c2d4b45e3d2 Will Deacon 2020-07-21 315 * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 316 * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 317 * compiler has support to do so.
eb5c2d4b45e3d2 Will Deacon 2020-07-21 318 */
eb5c2d4b45e3d2 Will Deacon 2020-07-21 319 #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 @320 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 321
:::::: The code at line 320 was first introduced by commit
:::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h
:::::: TO: Will Deacon <will@kernel.org>
:::::: CC: Will Deacon <will@kernel.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19736 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC
From: Nicholas Piggin @ 2021-04-09 1:08 UTC (permalink / raw)
To: Athira Rajeev, mpe; +Cc: nasastry, maddy, linuxppc-dev
In-Reply-To: <1617720464-1651-2-git-send-email-atrajeev@linux.vnet.ibm.com>
I was going to nitpick "overflown" here as something birds do, but some
sources says overflown is okay for past tense.
You could use "overflowed" for that, but I understand the issue with the
word: you are talking about counters that are currently in an "overflow"
state, but the overflow occurred in the past and is not still happening
so you "overflowing" doesn't exactly fit either.
overflown kind of works for some reason you can kind of use it for
present tense!
Excerpts from Athira Rajeev's message of April 7, 2021 12:47 am:
> Running perf fuzzer showed below in dmesg logs:
> "Can't find PMC that caused IRQ"
>
> This means a PMU exception happened, but none of the PMC's (Performance
> Monitor Counter) were found to be overflown. There are some corner cases
> that clears the PMCs after PMI gets masked. In such cases, the perf
> interrupt handler will not find the active PMC values that had caused
> the overflow and thus leads to this message while replaying.
>
> Case 1: PMU Interrupt happens during replay of other interrupts and
> counter values gets cleared by PMU callbacks before replay:
>
> During replay of interrupts like timer, __do_irq and doorbell exception, we
> conditionally enable interrupts via may_hard_irq_enable(). This could
> potentially create a window to generate a PMI. Since irq soft mask is set
> to ALL_DISABLED, the PMI will get masked here.
I wonder if may_hard_irq_enable shouldn't enable if PMI is soft
disabled. And also maybe replay should not set ALL_DISABLED if
there are no PMI interrupts pending.
Still, I think those are a bit more tricky and might take a while
to get right or just not be worth while, so I think your patch is
fine.
> We could get IPIs run before
> perf interrupt is replayed and the PMU events could deleted or stopped.
> This will change the PMU SPR values and resets the counters. Snippet of
> ftrace log showing PMU callbacks invoked in "__do_irq":
>
> <idle>-0 [051] dns. 132025441306354: __do_irq <-call_do_irq
> <idle>-0 [051] dns. 132025441306430: irq_enter <-__do_irq
> <idle>-0 [051] dns. 132025441306503: irq_enter_rcu <-__do_irq
> <idle>-0 [051] dnH. 132025441306599: xive_get_irq <-__do_irq
> <<>>
> <idle>-0 [051] dnH. 132025441307770: generic_smp_call_function_single_interrupt <-smp_ipi_demux_relaxed
> <idle>-0 [051] dnH. 132025441307839: flush_smp_call_function_queue <-smp_ipi_demux_relaxed
> <idle>-0 [051] dnH. 132025441308057: _raw_spin_lock <-event_function
> <idle>-0 [051] dnH. 132025441308206: power_pmu_disable <-perf_pmu_disable
> <idle>-0 [051] dnH. 132025441308337: power_pmu_del <-event_sched_out
> <idle>-0 [051] dnH. 132025441308407: power_pmu_read <-power_pmu_del
> <idle>-0 [051] dnH. 132025441308477: read_pmc <-power_pmu_read
> <idle>-0 [051] dnH. 132025441308590: isa207_disable_pmc <-power_pmu_del
> <idle>-0 [051] dnH. 132025441308663: write_pmc <-power_pmu_del
> <idle>-0 [051] dnH. 132025441308787: power_pmu_event_idx <-perf_event_update_userpage
> <idle>-0 [051] dnH. 132025441308859: rcu_read_unlock_strict <-perf_event_update_userpage
> <idle>-0 [051] dnH. 132025441308975: power_pmu_enable <-perf_pmu_enable
> <<>>
> <idle>-0 [051] dnH. 132025441311108: irq_exit <-__do_irq
> <idle>-0 [051] dns. 132025441311319: performance_monitor_exception <-replay_soft_interrupts
>
> Case 2: PMI's masked during local_* operations, example local_add.
> If the local_add operation happens within a local_irq_save, replay of
> PMI will be during local_irq_restore. Similar to case 1, this could
> also create a window before replay where PMU events gets deleted or
> stopped.
Here as well perhaps PMIs should be replayed if they are unmasked
even if other interrupts are still masked. Again that might be more
complexity than it's worth.
>
> Patch adds a fix to update the PMU callback functions (del,stop,enable) to
> check for pending perf interrupt. If there is an overflown PMC and pending
> perf interrupt indicated in Paca, clear the PMI bit in paca to drop that
> sample. In case of power_pmu_del, also clear the MMCR0 PMAO bit which
> otherwise could lead to spurious interrupts in some corner cases. Example,
> a timer after power_pmu_del which will re-enable interrupts since PMI is
> cleared and triggers a PMI again since PMAO bit is still set.
>
> We can't just replay PMI any time. Hence this approach is preferred rather
> than replaying PMI before resetting overflown PMC. Patch also documents
> core-book3s on a race condition which can trigger these PMC messages during
> idle path in PowerNV.
>
> Fixes: f442d004806e ("powerpc/64s: Add support to mask perf interrupts and replay them")
> Reported-by: Nageswara R Sastry <nasastry@in.ibm.com>
> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> Suggested-by: Madhavan Srinivasan <maddy@linux.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/pmc.h | 11 +++++++++
> arch/powerpc/perf/core-book3s.c | 55 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pmc.h b/arch/powerpc/include/asm/pmc.h
> index c6bbe9778d3c..97b4bd8de25b 100644
> --- a/arch/powerpc/include/asm/pmc.h
> +++ b/arch/powerpc/include/asm/pmc.h
> @@ -34,11 +34,22 @@ static inline void ppc_set_pmu_inuse(int inuse)
> #endif
> }
>
> +static inline int clear_paca_irq_pmi(void)
> +{
> + if (get_paca()->irq_happened & PACA_IRQ_PMI) {
> + WARN_ON_ONCE(mfmsr() & MSR_EE);
> + get_paca()->irq_happened &= ~PACA_IRQ_PMI;
> + return 1;
> + }
> + return 0;
> +}
Could you put this in arch/powerpc/include/asm/hw_irq.h and
rather than paca_irq, call it irq_pending perhaps
clear_pmi_irq_pending()
get_clear_pmi_irq_pending() if you're also testing it.
Could you add a little comment about the corner cases above it too?
The root cause seem to be interrupt replay while a masked PMI is
pending can result in other interrupts arriving which clear the PMU
overflow so the pending PMI must be cleared.
> +
> extern void power4_enable_pmcs(void);
>
> #else /* CONFIG_PPC64 */
>
> static inline void ppc_set_pmu_inuse(int inuse) { }
> +static inline int clear_paca_irq_pmi(void) { return 0; }
>
> #endif
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 766f064f00fb..18ca3c90f866 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -847,6 +847,20 @@ static void write_pmc(int idx, unsigned long val)
> }
> }
>
> +static int pmc_overflown(int idx)
> +{
> + unsigned long val[8];
> + int i;
> +
> + for (i = 0; i < ppmu->n_counter; i++)
> + val[i] = read_pmc(i + 1);
> +
> + if ((int)val[idx-1] < 0)
> + return 1;
> +
> + return 0;
> +}
> +
> /* Called from sysrq_handle_showregs() */
> void perf_event_print_debug(void)
> {
> @@ -1438,6 +1452,15 @@ static void power_pmu_enable(struct pmu *pmu)
> event = cpuhw->event[i];
> if (event->hw.idx && event->hw.idx != hwc_index[i] + 1) {
> power_pmu_read(event);
> + /*
> + * if the PMC corresponding to event->hw.idx is
> + * overflown, check if there is any pending perf
> + * interrupt set in paca. If so, disable the interrupt
> + * by clearing the paca bit for PMI since we are going
> + * to reset the PMC.
> + */
> + if (pmc_overflown(event->hw.idx))
> + clear_paca_irq_pmi();
If the pmc is not overflown, could there still be a PMI pending?
> write_pmc(event->hw.idx, 0);
> event->hw.idx = 0;
> }
> @@ -1474,6 +1497,10 @@ static void power_pmu_enable(struct pmu *pmu)
> event->hw.idx = idx;
> if (event->hw.state & PERF_HES_STOPPED)
> val = 0;
> +
> + /* See above for clear_paca_irq_pmi */
> + if (pmc_overflown(event->hw.idx))
> + clear_paca_irq_pmi();
> write_pmc(idx, val);
>
> perf_event_update_userpage(event);
> @@ -1619,6 +1646,7 @@ static void power_pmu_del(struct perf_event *event, int ef_flags)
> struct cpu_hw_events *cpuhw;
> long i;
> unsigned long flags;
> + unsigned long val_mmcr0;
>
> local_irq_save(flags);
> perf_pmu_disable(event->pmu);
> @@ -1636,6 +1664,22 @@ static void power_pmu_del(struct perf_event *event, int ef_flags)
> --cpuhw->n_events;
> ppmu->disable_pmc(event->hw.idx - 1, &cpuhw->mmcr);
> if (event->hw.idx) {
> + /*
> + * if the PMC corresponding to event->hw.idx is
> + * overflown, check if there is any pending perf
> + * interrupt set in paca. If so, disable the interrupt
> + * and clear the MMCR0 PMAO bit since we are going
> + * to reset the PMC and delete the event.
> + */
> + if (pmc_overflown(event->hw.idx)) {
> + if (clear_paca_irq_pmi()) {
> + val_mmcr0 = mfspr(SPRN_MMCR0);
> + val_mmcr0 &= ~MMCR0_PMAO;
> + write_mmcr0(cpuhw, val_mmcr0);
> + mb();
> + isync();
I don't know the perf subsystem, but just out of curiosity why does
MMCR0 need to be cleared only in this case? What if we disabled MSR[EE]
right before a perf interrupt came in, so we don't get a pending PMI
but the condition is still close to the same.
> + }
> write_pmc(event->hw.idx, 0);
> event->hw.idx = 0;
> }
> @@ -1714,6 +1758,8 @@ static void power_pmu_stop(struct perf_event *event, int ef_flags)
>
> local_irq_save(flags);
> perf_pmu_disable(event->pmu);
> + if (pmc_overflown(event->hw.idx))
> + clear_paca_irq_pmi();
>
> power_pmu_read(event);
> event->hw.state |= PERF_HES_STOPPED | PERF_HES_UPTODATE;
> @@ -2343,6 +2389,15 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> }
> }
> }
> +
> + /*
> + * During system wide profling or while specific CPU
> + * is monitored for an event, some corner cases could
> + * cause PMC to overflow in idle path. This will trigger
> + * a PMI after waking up from idle. Since counter values
> + * are _not_ saved/restored in idle path, can lead to
> + * below "Can't find PMC" message.
> + */
> if (unlikely(!found) && !arch_irq_disabled_regs(regs))
> printk_ratelimited(KERN_WARNING "Can't find PMC that caused IRQ\n");
>
> --
> 1.8.3.1
>
>
^ permalink raw reply
* Re: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
From: Daniel Walker @ 2021-04-09 1:23 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arch, arnd, microblaze, daniel, devicetree, linux-sh,
linuxppc-dev, linux-xtensa, x86, linux-kernel, linux-mips,
linux-mm, openrisc, nios2, linux-hexagon, sparclinux, akpm, will,
linux-riscv, linux-arm-kernel
In-Reply-To: <20210408190408.GA1724284@robh.at.kernel.org>
On Thu, Apr 08, 2021 at 02:04:08PM -0500, Rob Herring wrote:
> On Tue, Apr 06, 2021 at 10:38:36AM -0700, Daniel Walker wrote:
> > On Fri, Apr 02, 2021 at 03:18:21PM +0000, Christophe Leroy wrote:
> > > -config CMDLINE_BOOL
> > > - bool "Built-in kernel command line"
> > > - help
> > > - For most systems, it is firmware or second stage bootloader that
> > > - by default specifies the kernel command line options. However,
> > > - it might be necessary or advantageous to either override the
> > > - default kernel command line or add a few extra options to it.
> > > - For such cases, this option allows you to hardcode your own
> > > - command line options directly into the kernel. For that, you
> > > - should choose 'Y' here, and fill in the extra boot arguments
> > > - in CONFIG_CMDLINE.
> > > -
> > > - The built-in options will be concatenated to the default command
> > > - line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
> > > - command line will be ignored and replaced by the built-in string.
> > > -
> > > - Most MIPS systems will normally expect 'N' here and rely upon
> > > - the command line from the firmware or the second-stage bootloader.
> > > -
> >
> >
> > See how you complained that I have CMDLINE_BOOL in my changed, and you think it
> > shouldn't exist.
> >
> > Yet here mips has it, and you just deleted it with no feature parity in your
> > changes for this.
>
> AFAICT, CMDLINE_BOOL equates to a non-empty or empty CONFIG_CMDLINE. You
> seem to need it just because you have CMDLINE_PREPEND and
> CMDLINE_APPEND. If that's not it, what feature is missing? CMDLINE_BOOL
> is not a feature, but an implementation detail.
Not true.
It makes it easier to turn it all off inside the Kconfig , so it's for usability
and multiple architecture have it even with just CMDLINE as I was commenting
here.
Daniel
^ permalink raw reply
* Re: [PATCH 2/8] CMDLINE: drivers: of: ifdef out cmdline section
From: Daniel Walker @ 2021-04-09 1:26 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Ruslan Ruslichenko, Daniel Gimpelevich, Frank Rowand,
linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, xe-linux-external, Andrew Morton,
Will Deacon
In-Reply-To: <20210407225915.GA147338@robh.at.kernel.org>
On Wed, Apr 07, 2021 at 05:59:15PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 04:17:53PM -0700, Daniel Walker wrote:
> > On Tue, Mar 30, 2021 at 02:49:13PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 12:57 PM Daniel Walker <danielwa@cisco.com> wrote:
> > > >
> > > > It looks like there's some seepage of cmdline stuff into
> > > > the generic device tree code. This conflicts with the
> > > > generic cmdline implementation so I remove it in the case
> > > > when that's enabled.
> > > >
> > > > Cc: xe-linux-external@cisco.com
> > > > Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
> > > > Signed-off-by: Daniel Walker <danielwa@cisco.com>
> > > > ---
> > > > drivers/of/fdt.c | 14 ++++++++++++++
> > > > 1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > > > index dcc1dd96911a..d8805cd9717a 100644
> > > > --- a/drivers/of/fdt.c
> > > > +++ b/drivers/of/fdt.c
> > > > @@ -25,6 +25,7 @@
> > > > #include <linux/serial_core.h>
> > > > #include <linux/sysfs.h>
> > > > #include <linux/random.h>
> > > > +#include <linux/cmdline.h>
> > > >
> > > > #include <asm/setup.h> /* for COMMAND_LINE_SIZE */
> > > > #include <asm/page.h>
> > > > @@ -1050,6 +1051,18 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
> > > >
> > > > /* Retrieve command line */
> > > > p = of_get_flat_dt_prop(node, "bootargs", &l);
> > > > +
> > > > +#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_GENERIC_CMDLINE_OF)
> > >
> > > Moving in the wrong direction... This code already has too many
> > > #ifdef's. I like Christophe's version as it gets rid of all the code
> > > here.
> >
> > It's temporary .. Notice CONFIG_GENERIC_CMDLINE_OF is only used on PowerPC. I
> > experienced doubling on arm64 when this was used (i.e. the append and prepend
> > was added twice).
> >
> > I don't think there are any other users which can't be moved outside the device
> > tree code, but powerpc uses this function three times during boot up plus the
> > prom_init user. It's possible to use the generic command line in all four places,
> > but it become space inefficient.
>
> What's the 3rd use? I count kaslr code and in
> early_init_dt_scan_chosen_ppc. Do we need to build the command line for
> kaslr seed? Getting any build time value from the kernel is pointless.
I think I may have been mistaken. I added a dump_stack() , but there may have
been other stack traces during bootup on prior -rcX's I was testing.
I re-ran the test and I only see one user on powerpc and powerpc64,
powerpc64,
[ T0] Call Trace:
[ T0] [c000000001517d00] [c00000000077e910] dump_stack+0xc4/0x114 (unreliable)
[ T0] [c000000001517d50] [c000000001186fb4] early_init_dt_scan_chosen+0x238/0x324
[ T0] [c000000001517de0] [c000000001138b00] early_init_dt_scan_chosen_ppc+0x20/0x194
[ T0] [c000000001517e10] [c000000001186ae0] of_scan_flat_dt+0xc8/0x130
[ T0] [c000000001517e70] [c000000001139404] early_init_devtree+0xa4/0x48c
[ T0] [c000000001517f10] [c00000000113ac90] early_setup+0xc8/0x254
[ T0] [c000000001517f90] [000000000000c754] 0xc754
powerpc32,
Call Trace:
[c06bbee0] [c067e334] early_init_dt_scan_chosen+0xf8/0x1dc (unreliable)
[c06bbf10] [c0666ec4] early_init_dt_scan_chosen_ppc+0x18/0x6c
[c06bbf30] [c067e048] of_scan_flat_dt+0x98/0xf4
[c06bbf70] [c0667234] early_init_devtree+0x48/0x2d0
[c06bbfb0] [c06679cc] machine_init+0x98/0xcc
[c06bbff0] [c0000398] set_ivor+0x114/0x154
I think it would be possible to just move the generic handling entire into
architecture code.
Daniel
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mm/hash: Avoid resizing-down HPT on first memory hotplug
From: Leonardo Bras @ 2021-04-09 2:16 UTC (permalink / raw)
To: David Gibson
Cc: Nathan Lynch, David Hildenbrand, Scott Cheloha, linux-kernel,
linuxppc-dev, Nicholas Piggin, Bharata B Rao, Paul Mackerras,
Sandipan Das, Aneesh Kumar K.V, Andrew Morton, Laurent Dufour,
Logan Gunthorpe, Dan Williams, Mike Rapoport
In-Reply-To: <YFg+Edy6dfmZx3lr@yekko.fritz.box>
Hello David, thanks for your feedback.
On Mon, 2021-03-22 at 17:49 +1100, David Gibson wrote:
> I don't love this approach. Adding the extra flag at this level seems
> a bit inelegant, and it means we're passing up an easy opportunity to
> reduce our resource footprint on the host.
I understand, but trying to reduce resource footprint in host, and
mostly failing is what causes hot-add and hot-remove to take so long.
> But... maybe we'll have to do it. I'd like to see if we can get
> things to work well enough with just the "batching" to avoid multiple
> resize attempts first.
This batching is something I had thought a lot about.
Problem is that there are a lot of generic interfaces between memory
hotplug and actually resizing HPT. I tried a simpler approach in
patches 2 & 3, so I don't touch much stuff there.
Best regards,
Leonardo Bras
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS f2b8ef18c8e0634e176be99dcf242e515cfdb1d3
From: kernel test robot @ 2021-04-09 2:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: f2b8ef18c8e0634e176be99dcf242e515cfdb1d3 Automatic merge of 'master' into merge (2021-04-07 21:54)
elapsed time: 2263m
configs tested: 165
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
nds32 alldefconfig
powerpc motionpro_defconfig
powerpc linkstation_defconfig
mips capcella_defconfig
arm pxa168_defconfig
arm lpc18xx_defconfig
arc haps_hs_defconfig
riscv alldefconfig
powerpc mpc83xx_defconfig
openrisc simple_smp_defconfig
arm gemini_defconfig
mips mtx1_defconfig
arm pxa255-idp_defconfig
m68k stmark2_defconfig
mips maltaaprp_defconfig
m68k amcore_defconfig
powerpc currituck_defconfig
sh hp6xx_defconfig
arc nsimosci_hs_defconfig
s390 zfcpdump_defconfig
nios2 3c120_defconfig
m68k m5407c3_defconfig
powerpc klondike_defconfig
powerpc ppc44x_defconfig
arm at91_dt_defconfig
powerpc mpc8272_ads_defconfig
sh sh7770_generic_defconfig
arm collie_defconfig
mips ip28_defconfig
sh r7780mp_defconfig
m68k mvme16x_defconfig
arm multi_v5_defconfig
powerpc kmeter1_defconfig
sh urquell_defconfig
sh kfr2r09_defconfig
xtensa audio_kc705_defconfig
xtensa iss_defconfig
arm spear3xx_defconfig
powerpc ppc64e_defconfig
mips rb532_defconfig
powerpc mpc834x_mds_defconfig
arm zeus_defconfig
openrisc or1klitex_defconfig
sh rts7751r2dplus_defconfig
powerpc maple_defconfig
arm shmobile_defconfig
mips maltaup_defconfig
riscv nommu_k210_sdcard_defconfig
um x86_64_defconfig
arc vdk_hs38_smp_defconfig
arm u8500_defconfig
arm ezx_defconfig
arm ixp4xx_defconfig
sh sh7785lcr_32bit_defconfig
powerpc sbc8548_defconfig
arm netwinder_defconfig
sh lboxre2_defconfig
mips loongson1c_defconfig
arm rpc_defconfig
powerpc warp_defconfig
sh ul2_defconfig
powerpc mpc5200_defconfig
powerpc ep88xc_defconfig
m68k amiga_defconfig
arm colibri_pxa270_defconfig
mips ip22_defconfig
arm shannon_defconfig
powerpc xes_mpc85xx_defconfig
mips decstation_64_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210408
x86_64 randconfig-a005-20210408
x86_64 randconfig-a003-20210408
x86_64 randconfig-a001-20210408
x86_64 randconfig-a002-20210408
x86_64 randconfig-a006-20210408
i386 randconfig-a006-20210408
i386 randconfig-a003-20210408
i386 randconfig-a001-20210408
i386 randconfig-a004-20210408
i386 randconfig-a005-20210408
i386 randconfig-a002-20210408
i386 randconfig-a006-20210407
i386 randconfig-a003-20210407
i386 randconfig-a001-20210407
i386 randconfig-a004-20210407
i386 randconfig-a002-20210407
i386 randconfig-a005-20210407
x86_64 randconfig-a014-20210407
x86_64 randconfig-a015-20210407
x86_64 randconfig-a013-20210407
x86_64 randconfig-a011-20210407
x86_64 randconfig-a012-20210407
x86_64 randconfig-a016-20210407
i386 randconfig-a014-20210408
i386 randconfig-a016-20210408
i386 randconfig-a011-20210408
i386 randconfig-a012-20210408
i386 randconfig-a013-20210408
i386 randconfig-a015-20210408
i386 randconfig-a014-20210407
i386 randconfig-a011-20210407
i386 randconfig-a016-20210407
i386 randconfig-a012-20210407
i386 randconfig-a015-20210407
i386 randconfig-a013-20210407
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a014-20210408
x86_64 randconfig-a015-20210408
x86_64 randconfig-a012-20210408
x86_64 randconfig-a011-20210408
x86_64 randconfig-a013-20210408
x86_64 randconfig-a016-20210408
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD REGRESSION 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb
From: kernel test robot @ 2021-04-09 2:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler
Error/Warning reports:
https://lore.kernel.org/linuxppc-dev/202104090230.ACwnO03u-lkp@intel.com
https://lore.kernel.org/linuxppc-dev/202104090827.jH0WBiCC-lkp@intel.com
Error/Warning in current branch:
include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- powerpc-randconfig-s031-20210408
| |-- drivers-w1-slaves-w1_ds28e04.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-char-const-noderef-__user-_gu_addr-got-char-const-buf
| `-- drivers-w1-slaves-w1_ds28e04.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-char-noderef-__user-_pu_addr-got-char-buf
`-- powerpc64-randconfig-c004-20210408
`-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:BUILD_BUG_ON-failed:TASK_SIZE-MODULES_VADDR
elapsed time: 727m
configs tested: 166
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
riscv allyesconfig
i386 allyesconfig
mips rt305x_defconfig
um allnoconfig
sh urquell_defconfig
sh titan_defconfig
arm ezx_defconfig
arm oxnas_v6_defconfig
powerpc akebono_defconfig
arm eseries_pxa_defconfig
arm pleb_defconfig
m68k amcore_defconfig
sparc sparc32_defconfig
powerpc ppa8548_defconfig
x86_64 alldefconfig
mips maltaup_xpa_defconfig
xtensa cadence_csp_defconfig
powerpc allnoconfig
powerpc mgcoge_defconfig
powerpc linkstation_defconfig
sh migor_defconfig
mips lemote2f_defconfig
m68k m5407c3_defconfig
arm lart_defconfig
arm spitz_defconfig
arm palmz72_defconfig
arm lpc32xx_defconfig
ia64 alldefconfig
powerpc mpc832x_mds_defconfig
powerpc ppc6xx_defconfig
sh sh7770_generic_defconfig
sh sh2007_defconfig
mips ip28_defconfig
sh r7780mp_defconfig
m68k mvme16x_defconfig
arm multi_v5_defconfig
powerpc kmeter1_defconfig
arc nsimosci_hs_defconfig
arm clps711x_defconfig
xtensa xip_kc705_defconfig
m68k bvme6000_defconfig
h8300 alldefconfig
riscv nommu_k210_defconfig
mips loongson1b_defconfig
mips decstation_64_defconfig
powerpc ppc64e_defconfig
mips rb532_defconfig
powerpc mpc834x_mds_defconfig
sh landisk_defconfig
powerpc arches_defconfig
m68k hp300_defconfig
s390 debug_defconfig
sh kfr2r09-romimage_defconfig
arm mxs_defconfig
mips malta_defconfig
arm u8500_defconfig
sh se7206_defconfig
nios2 alldefconfig
arc vdk_hs38_defconfig
sh sdk7786_defconfig
powerpc mpc83xx_defconfig
arm pxa3xx_defconfig
um x86_64_defconfig
arm zeus_defconfig
arm footbridge_defconfig
powerpc warp_defconfig
mips ip22_defconfig
m68k multi_defconfig
sh lboxre2_defconfig
powerpc mpc5200_defconfig
powerpc ep88xc_defconfig
m68k amiga_defconfig
arm colibri_pxa270_defconfig
arm xcep_defconfig
ia64 zx1_defconfig
sh sh7785lcr_32bit_defconfig
arm dove_defconfig
powerpc mpc85xx_cds_defconfig
arm shannon_defconfig
powerpc xes_mpc85xx_defconfig
arm at91_dt_defconfig
sh sh7724_generic_defconfig
arc vdk_hs38_smp_defconfig
mips ip32_defconfig
powerpc mpc8272_ads_defconfig
openrisc defconfig
riscv nommu_k210_sdcard_defconfig
mips ath25_defconfig
mips ath79_defconfig
powerpc ps3_defconfig
arm gemini_defconfig
arm realview_defconfig
arm iop32x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a004-20210408
x86_64 randconfig-a005-20210408
x86_64 randconfig-a003-20210408
x86_64 randconfig-a001-20210408
x86_64 randconfig-a002-20210408
x86_64 randconfig-a006-20210408
i386 randconfig-a006-20210408
i386 randconfig-a003-20210408
i386 randconfig-a001-20210408
i386 randconfig-a004-20210408
i386 randconfig-a005-20210408
i386 randconfig-a002-20210408
i386 randconfig-a014-20210408
i386 randconfig-a016-20210408
i386 randconfig-a011-20210408
i386 randconfig-a012-20210408
i386 randconfig-a013-20210408
i386 randconfig-a015-20210408
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a014-20210408
x86_64 randconfig-a015-20210408
x86_64 randconfig-a012-20210408
x86_64 randconfig-a011-20210408
x86_64 randconfig-a013-20210408
x86_64 randconfig-a016-20210408
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS c46bbf5d2defae50d61ddf31502017ee8952af83
From: kernel test robot @ 2021-04-09 2:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: c46bbf5d2defae50d61ddf31502017ee8952af83 powerpc/32: Remove powerpc specific definition of 'ptrdiff_t'
elapsed time: 728m
configs tested: 165
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
riscv allyesconfig
i386 allyesconfig
mips rt305x_defconfig
um allnoconfig
sh urquell_defconfig
sh titan_defconfig
arm ezx_defconfig
arm oxnas_v6_defconfig
powerpc akebono_defconfig
arm eseries_pxa_defconfig
arm pleb_defconfig
m68k amcore_defconfig
sparc sparc32_defconfig
powerpc ppa8548_defconfig
x86_64 alldefconfig
mips maltaup_xpa_defconfig
xtensa cadence_csp_defconfig
powerpc allnoconfig
powerpc mgcoge_defconfig
powerpc linkstation_defconfig
sh migor_defconfig
mips lemote2f_defconfig
m68k m5407c3_defconfig
arm lart_defconfig
arm spitz_defconfig
arm palmz72_defconfig
arm lpc32xx_defconfig
ia64 alldefconfig
powerpc mpc832x_mds_defconfig
powerpc ppc6xx_defconfig
sh sh7770_generic_defconfig
sh sh2007_defconfig
mips ip28_defconfig
sh r7780mp_defconfig
m68k mvme16x_defconfig
arm multi_v5_defconfig
powerpc kmeter1_defconfig
arc nsimosci_hs_defconfig
arm clps711x_defconfig
xtensa xip_kc705_defconfig
m68k bvme6000_defconfig
h8300 alldefconfig
riscv nommu_k210_defconfig
mips loongson1b_defconfig
mips decstation_64_defconfig
powerpc ppc64e_defconfig
mips rb532_defconfig
powerpc mpc834x_mds_defconfig
sh landisk_defconfig
powerpc arches_defconfig
parisc allyesconfig
m68k hp300_defconfig
s390 debug_defconfig
sh kfr2r09-romimage_defconfig
arm mxs_defconfig
mips malta_defconfig
arm u8500_defconfig
um x86_64_defconfig
arc vdk_hs38_smp_defconfig
arm ixp4xx_defconfig
sh sh7785lcr_32bit_defconfig
sh se7206_defconfig
nios2 alldefconfig
arc vdk_hs38_defconfig
sh sdk7786_defconfig
powerpc mpc83xx_defconfig
arm pxa3xx_defconfig
arm zeus_defconfig
arm footbridge_defconfig
powerpc warp_defconfig
mips ip22_defconfig
m68k multi_defconfig
sh lboxre2_defconfig
arm64 alldefconfig
powerpc mpc5200_defconfig
powerpc ep88xc_defconfig
m68k amiga_defconfig
arm colibri_pxa270_defconfig
arm xcep_defconfig
ia64 zx1_defconfig
arm dove_defconfig
powerpc mpc85xx_cds_defconfig
arm shannon_defconfig
powerpc xes_mpc85xx_defconfig
arm at91_dt_defconfig
sh sh7724_generic_defconfig
mips ip32_defconfig
arm realview_defconfig
arm mvebu_v7_defconfig
arm collie_defconfig
powerpc ps3_defconfig
arm gemini_defconfig
arm iop32x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a004-20210408
x86_64 randconfig-a005-20210408
x86_64 randconfig-a003-20210408
x86_64 randconfig-a001-20210408
x86_64 randconfig-a002-20210408
x86_64 randconfig-a006-20210408
i386 randconfig-a006-20210408
i386 randconfig-a003-20210408
i386 randconfig-a001-20210408
i386 randconfig-a004-20210408
i386 randconfig-a005-20210408
i386 randconfig-a002-20210408
i386 randconfig-a014-20210408
i386 randconfig-a016-20210408
i386 randconfig-a011-20210408
i386 randconfig-a012-20210408
i386 randconfig-a013-20210408
i386 randconfig-a015-20210408
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a014-20210408
x86_64 randconfig-a015-20210408
x86_64 randconfig-a012-20210408
x86_64 randconfig-a011-20210408
x86_64 randconfig-a013-20210408
x86_64 randconfig-a016-20210408
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/mm/hash: Avoid multiple HPT resize-ups on memory hotplug
From: Leonardo Bras @ 2021-04-09 2:51 UTC (permalink / raw)
To: David Gibson
Cc: Nathan Lynch, David Hildenbrand, Scott Cheloha, linux-kernel,
linuxppc-dev, Nicholas Piggin, Bharata B Rao, Paul Mackerras,
Sandipan Das, Aneesh Kumar K.V, Andrew Morton, Laurent Dufour,
Logan Gunthorpe, Dan Williams, Mike Rapoport
In-Reply-To: <YFhNd42RvobCV8tF@yekko.fritz.box>
Hello David, thanks for the feedback!
On Mon, 2021-03-22 at 18:55 +1100, David Gibson wrote:
> > +void hash_memory_batch_expand_prepare(unsigned long newsize)
> > +{
> > + /*
> > + * Resizing-up HPT should never fail, but there are some cases system starts with higher
> > + * SHIFT than required, and we go through the funny case of resizing HPT down while
> > + * adding memory
> > + */
> > +
> > + while (resize_hpt_for_hotplug(newsize, false) == -ENOSPC) {
> > + newsize *= 2;
> > + pr_warn("Hash collision while resizing HPT\n");
>
> This unbounded increase in newsize makes me nervous - we should be
> bounded by the current size of the HPT at least. In practice we
> should be fine, since the resize should always succeed by the time we
> reach our current HPT size, but that's far from obvious from this
> point in the code.
Sure, I will add bounds in v2.
>
> And... you're doubling newsize which is a value which might not be a
> power of 2. I'm wondering if there's an edge case where this could
> actually cause us to skip the current size and erroneously resize to
> one bigger than we have currently.
I also though that at the start, but it seems quite reliable.
Before using this value, htab_shift_for_mem_size() will always round it
to next power of 2.
Ex.
Any value between 0b0101 and 0b1000 will be rounded to 0b1000 for shift
calculation. If we multiply it by 2 (same as << 1), we have that
anything between 0b01010 and 0b10000 will be rounded to 0b10000.
This works just fine as long as we are multiplying.
Division may have the behavior you expect, as 0b0101 >> 1 would become
0b010 and skip a shift.
> > +void memory_batch_expand_prepare(unsigned long newsize)
>
> This wrapper doesn't seem useful.
Yeah, it does little, but I can't just jump into hash_* functions
directly from hotplug-memory.c, without even knowing if it's using hash
pagetables. (in case the suggestion would be test for disable_radix
inside hash_memory_batch*)
>
> > +{
> > + if (!radix_enabled())
> > + hash_memory_batch_expand_prepare(newsize);
> > +}
> > #endif /* CONFIG_MEMORY_HOTPLUG */
> >
> >
> > + memory_batch_expand_prepare(memblock_phys_mem_size() +
> > + drmem_info->n_lmbs * drmem_lmb_size());
>
> This doesn't look right. memory_add_by_index() is adding a *single*
> LMB, I think using drmem_info->n_lmbs here means you're counting this
> as adding again as much memory as you already have hotplugged.
Yeah, my mistake. This makes sense.
I will change it to something like
memblock_phys_mem_size() + drmem_lmb_size()
> >
> > + memory_batch_expand_prepare(memblock_phys_mem_size() + lmbs_to_add * drmem_lmb_size());
> > +
> > for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
> > if (lmb->flags & DRCONF_MEM_ASSIGNED)
> > continue;
>
> I don't see memory_batch_expand_prepare() suppressing any existing HPT
> resizes. Won't this just resize to the right size for the full add,
> then resize several times again as we perform the add? Or.. I guess
> that will be suppressed by patch 1/3.
Correct.
> That's seems kinda fragile, though.
What do you mean by fragile here?
What would you suggest doing different?
Best regards,
Leonardo Bras
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/mm/hash: Avoid multiple HPT resize-downs on memory hotunplug
From: Leonardo Bras @ 2021-04-09 3:31 UTC (permalink / raw)
To: David Gibson
Cc: Nathan Lynch, David Hildenbrand, Scott Cheloha, linux-kernel,
linuxppc-dev, Nicholas Piggin, Bharata B Rao, Paul Mackerras,
Sandipan Das, Aneesh Kumar K.V, Andrew Morton, Laurent Dufour,
Logan Gunthorpe, Dan Williams, Mike Rapoport
In-Reply-To: <YFksMw8Hw/mC48yb@yekko.fritz.box>
Hello David, thanks for commenting.
On Tue, 2021-03-23 at 10:45 +1100, David Gibson wrote:
> > @@ -805,6 +808,10 @@ static int resize_hpt_for_hotplug(unsigned long new_mem_size, bool shrinking)
> > if (shrinking) {
> >
> > + /* When batch removing entries, only resizes HPT at the end. */
> > + if (atomic_read_acquire(&hpt_resize_disable))
> > + return 0;
> > +
>
> I'm not quite convinced by this locking. Couldn't hpt_resize_disable
> be set after this point, but while you're still inside
> resize_hpt_for_hotplug()? Probably better to use an explicit mutex
> (and mutex_trylock()) to make the critical sections clearer.
Sure, I can do that for v2.
> Except... do we even need the fancy mechanics to suppress the resizes
> in one place to do them elswhere. Couldn't we just replace the
> existing resize calls with the batched ones?
How do you think of having batched resizes-down in HPT?
Other than the current approach, I could only think of a way that would
touch a lot of generic code, and/or duplicate some functions, as
dlpar_add_lmb() does a lot of other stuff.
> > +void hash_memory_batch_shrink_end(void)
> > +{
> > + unsigned long newsize;
> > +
> > + /* Re-enables HPT resize-down after hot-unplug */
> > + atomic_set_release(&hpt_resize_disable, 0);
> > +
> > + newsize = memblock_phys_mem_size();
> > + /* Resize to smallest SHIFT possible */
> > + while (resize_hpt_for_hotplug(newsize, true) == -ENOSPC) {
> > + newsize *= 2;
>
> As noted earlier, doing this without an explicit cap on the new hpt
> size (of the existing size) this makes me nervous.
>
I can add a stop in v2.
> Less so, but doing
> the calculations on memory size, rather than explictly on HPT size /
> HPT order also seems kinda clunky.
Agree, but at this point, it would seem kind of a waste to find the
shift from newsize, then calculate (1 << shift) for each retry of
resize_hpt_for_hotplug() only to point that we are retrying the order
value.
But sure, if you think it looks better, I can change that.
> > +void memory_batch_shrink_begin(void)
> > +{
> > + if (!radix_enabled())
> > + hash_memory_batch_shrink_begin();
> > +}
> > +
> > +void memory_batch_shrink_end(void)
> > +{
> > + if (!radix_enabled())
> > + hash_memory_batch_shrink_end();
> > +}
>
> Again, these wrappers don't seem particularly useful to me.
Options would be add 'if (!radix_enabled())' to hotplug-memory.c
functions or to hash* functions, which look kind of wrong.
> > + memory_batch_shrink_end();
>
> remove_by_index only removes a single LMB, so there's no real point to
> batching here.
Sure, will be fixed for v2.
> > @@ -700,6 +712,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
> > if (lmbs_added != lmbs_to_add) {
> > pr_err("Memory hot-add failed, removing any added LMBs\n");
> >
> > + memory_batch_shrink_begin();
>
>
> The effect of these on the memory grow path is far from clear.
>
On hotplug, HPT is resized-up before adding LMBs.
On hotunplug, HPT is resized-down after removing LMBs.
And each one has it's own mechanism to batch HPT resizes...
I can't understand exactly how using it on hotplug fail path can be any
different than using it on hotunplug.
>
Can you please help me understanding this?
Best regards,
Leonardo Bras
^ permalink raw reply
* Re: [PATCH v6 30/48] KVM: PPC: Book3S HV P9: Implement the rest of the P9 path in C
From: Alexey Kardashevskiy @ 2021-04-09 3:57 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20210405011948.675354-31-npiggin@gmail.com>
On 05/04/2021 11:19, Nicholas Piggin wrote:
> Almost all logic is moved to C, by introducing a new in_guest mode for
> the P9 path that branches very early in the KVM interrupt handler to
> P9 exit code.
>
> The main P9 entry and exit assembly is now only about 160 lines of low
> level stack setup and register save/restore, plus a bad-interrupt
> handler.
>
> There are two motivations for this, the first is just make the code more
> maintainable being in C. The second is to reduce the amount of code
> running in a special KVM mode, "realmode". In quotes because with radix
> it is no longer necessarily real-mode in the MMU, but it still has to be
> treated specially because it may be in real-mode, and has various
> important registers like PID, DEC, TB, etc set to guest. This is hostile
> to the rest of Linux and can't use arbitrary kernel functionality or be
> instrumented well.
>
> This initial patch is a reasonably faithful conversion of the asm code,
> but it does lack any loop to return quickly back into the guest without
> switching out of realmode in the case of unimportant or easily handled
> interrupts. As explained in previous changes, handling HV interrupts
> in real mode is not so important for P9.
>
> Use of Linux 64s interrupt entry code register conventions including
> paca EX_ save areas are brought into the KVM code. There is no point
> shuffling things into different paca save areas and making up a
> different calling convention for KVM.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/asm-prototypes.h | 3 +-
> arch/powerpc/include/asm/kvm_asm.h | 3 +-
> arch/powerpc/include/asm/kvm_book3s_64.h | 8 +
> arch/powerpc/include/asm/kvm_host.h | 7 +-
> arch/powerpc/kernel/security.c | 5 +-
> arch/powerpc/kvm/Makefile | 1 +
> arch/powerpc/kvm/book3s_64_entry.S | 247 ++++++++++++++++++++++
> arch/powerpc/kvm/book3s_hv.c | 9 +-
> arch/powerpc/kvm/book3s_hv_interrupt.c | 218 +++++++++++++++++++
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 125 +----------
> 10 files changed, 501 insertions(+), 125 deletions(-)
> create mode 100644 arch/powerpc/kvm/book3s_hv_interrupt.c
>
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
> index 939f3c94c8f3..7c74c80ed994 100644
> --- a/arch/powerpc/include/asm/asm-prototypes.h
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -122,6 +122,7 @@ extern s32 patch__call_flush_branch_caches3;
> extern s32 patch__flush_count_cache_return;
> extern s32 patch__flush_link_stack_return;
> extern s32 patch__call_kvm_flush_link_stack;
> +extern s32 patch__call_kvm_flush_link_stack_p9;
> extern s32 patch__memset_nocache, patch__memcpy_nocache;
>
> extern long flush_branch_caches;
> @@ -142,7 +143,7 @@ void kvmhv_load_host_pmu(void);
> void kvmhv_save_guest_pmu(struct kvm_vcpu *vcpu, bool pmu_in_use);
> void kvmhv_load_guest_pmu(struct kvm_vcpu *vcpu);
>
> -int __kvmhv_vcpu_entry_p9(struct kvm_vcpu *vcpu);
> +void kvmppc_p9_enter_guest(struct kvm_vcpu *vcpu);
>
> long kvmppc_h_set_dabr(struct kvm_vcpu *vcpu, unsigned long dabr);
> long kvmppc_h_set_xdabr(struct kvm_vcpu *vcpu, unsigned long dabr,
> diff --git a/arch/powerpc/include/asm/kvm_asm.h b/arch/powerpc/include/asm/kvm_asm.h
> index a3633560493b..b4f9996bd331 100644
> --- a/arch/powerpc/include/asm/kvm_asm.h
> +++ b/arch/powerpc/include/asm/kvm_asm.h
> @@ -146,7 +146,8 @@
> #define KVM_GUEST_MODE_GUEST 1
> #define KVM_GUEST_MODE_SKIP 2
> #define KVM_GUEST_MODE_GUEST_HV 3
> -#define KVM_GUEST_MODE_HOST_HV 4
> +#define KVM_GUEST_MODE_GUEST_HV_FAST 4 /* ISA v3.0 with host radix mode */
> +#define KVM_GUEST_MODE_HOST_HV 5
>
> #define KVM_INST_FETCH_FAILED -1
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
> index 9bb9bb370b53..c214bcffb441 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_64.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_64.h
> @@ -153,9 +153,17 @@ static inline bool kvmhv_vcpu_is_radix(struct kvm_vcpu *vcpu)
> return radix;
> }
>
> +int __kvmhv_vcpu_entry_p9(struct kvm_vcpu *vcpu);
> +
> #define KVM_DEFAULT_HPT_ORDER 24 /* 16MB HPT by default */
> #endif
>
> +/*
> + * Invalid HDSISR value which is used to indicate when HW has not set the reg.
> + * Used to work around an errata.
> + */
> +#define HDSISR_CANARY 0x7fff
> +
> /*
> * We use a lock bit in HPTE dword 0 to synchronize updates and
> * accesses to each HPTE, and another bit to indicate non-present
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 05fb00d37609..fa0083345b11 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -690,7 +690,12 @@ struct kvm_vcpu_arch {
> ulong fault_dar;
> u32 fault_dsisr;
> unsigned long intr_msr;
> - ulong fault_gpa; /* guest real address of page fault (POWER9) */
> + /*
> + * POWER9 and later, fault_gpa contains the guest real address of page
> + * fault for a radix guest, or segment descriptor (equivalent to result
> + * from slbmfev of SLB entry that translated the EA) for hash guests.
> + */
> + ulong fault_gpa;
> #endif
>
> #ifdef CONFIG_BOOKE
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> index e4e1a94ccf6a..3a607c11f20f 100644
> --- a/arch/powerpc/kernel/security.c
> +++ b/arch/powerpc/kernel/security.c
> @@ -430,16 +430,19 @@ device_initcall(stf_barrier_debugfs_init);
>
> static void update_branch_cache_flush(void)
> {
> - u32 *site;
> + u32 *site, __maybe_unused *site2;
>
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> site = &patch__call_kvm_flush_link_stack;
> + site2 = &patch__call_kvm_flush_link_stack_p9;
> // This controls the branch from guest_exit_cont to kvm_flush_link_stack
> if (link_stack_flush_type == BRANCH_CACHE_FLUSH_NONE) {
> patch_instruction_site(site, ppc_inst(PPC_INST_NOP));
> + patch_instruction_site(site2, ppc_inst(PPC_INST_NOP));
> } else {
> // Could use HW flush, but that could also flush count cache
> patch_branch_site(site, (u64)&kvm_flush_link_stack, BRANCH_SET_LINK);
> + patch_branch_site(site2, (u64)&kvm_flush_link_stack, BRANCH_SET_LINK);
> }
> #endif
>
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index cdd119028f64..ca7c86aa9360 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -88,6 +88,7 @@ kvm-book3s_64-builtin-tm-objs-$(CONFIG_PPC_TRANSACTIONAL_MEM) += \
>
> ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
> + book3s_hv_interrupt.o \
> book3s_hv_hmi.o \
> book3s_hv_rmhandlers.o \
> book3s_hv_rm_mmu.o \
> diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
> index 0c79c89c6a4b..d98ad580fd98 100644
> --- a/arch/powerpc/kvm/book3s_64_entry.S
> +++ b/arch/powerpc/kvm/book3s_64_entry.S
> @@ -1,11 +1,16 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> #include <asm/asm-offsets.h>
> #include <asm/cache.h>
> +#include <asm/code-patching-asm.h>
> #include <asm/exception-64s.h>
> +#include <asm/export.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_book3s_asm.h>
> +#include <asm/mmu.h>
> #include <asm/ppc_asm.h>
> +#include <asm/ptrace.h>
> #include <asm/reg.h>
> +#include <asm/ultravisor-api.h>
>
> /*
> * These are branched to from interrupt handlers in exception-64s.S which set
> @@ -29,10 +34,15 @@
> .global kvmppc_hcall
> .balign IFETCH_ALIGN_BYTES
> kvmppc_hcall:
> + lbz r10,HSTATE_IN_GUEST(r13)
> + cmpwi r10,KVM_GUEST_MODE_GUEST_HV_FAST
> + beq kvmppc_p9_exit_hcall
> ld r10,PACA_EXGEN+EX_R13(r13)
> SET_SCRATCH0(r10)
> li r10,0xc00
> /* Now we look like kvmppc_interrupt */
> + li r11,PACA_EXGEN
> + b 1f
>
> /*
> * KVM interrupt entry occurs after GEN_INT_ENTRY runs, and follows that
> @@ -53,6 +63,12 @@ kvmppc_hcall:
> .global kvmppc_interrupt
> .balign IFETCH_ALIGN_BYTES
> kvmppc_interrupt:
> + std r10,HSTATE_SCRATCH0(r13)
> + lbz r10,HSTATE_IN_GUEST(r13)
> + cmpwi r10,KVM_GUEST_MODE_GUEST_HV_FAST
> + beq kvmppc_p9_exit_interrupt
> + ld r10,HSTATE_SCRATCH0(r13)
> + lbz r11,HSTATE_IN_GUEST(r13)
> li r11,PACA_EXGEN
> cmpdi r10,0x200
> bgt+ 1f
> @@ -154,3 +170,234 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> GET_SCRATCH0(r13)
> HRFI_TO_KERNEL
> #endif
> +
> +/* Stack frame offsets for kvmppc_hv_entry */
> +#define SFS (144 + STACK_FRAME_MIN_SIZE)
> +#define STACK_SLOT_NVGPRS (SFS - 144) /* 18 gprs */
> +
> +/*
> + * void kvmppc_p9_enter_guest(struct vcpu *vcpu);
> + *
> + * Enter the guest on a ISAv3.0 or later system where we have exactly
> + * one vcpu per vcore, and both the host and guest are radix, and threads
> + * are set to "indepdent mode".
> + */
> +.balign IFETCH_ALIGN_BYTES
> +_GLOBAL(kvmppc_p9_enter_guest)
> +EXPORT_SYMBOL_GPL(kvmppc_p9_enter_guest)
> + mflr r0
> + std r0,PPC_LR_STKOFF(r1)
> + stdu r1,-SFS(r1)
> +
> + std r1,HSTATE_HOST_R1(r13)
> +
> + mfcr r4
> + stw r4,SFS+8(r1)
> +
> + reg = 14
> + .rept 18
> + std reg,STACK_SLOT_NVGPRS + ((reg - 14) * 8)(r1)
> + reg = reg + 1
> + .endr
> +
> + ld r4,VCPU_LR(r3)
> + mtlr r4
> + ld r4,VCPU_CTR(r3)
> + mtctr r4
> + ld r4,VCPU_XER(r3)
> + mtspr SPRN_XER,r4
> +
> + ld r1,VCPU_CR(r3)
> +
> +BEGIN_FTR_SECTION
> + ld r4,VCPU_CFAR(r3)
> + mtspr SPRN_CFAR,r4
> +END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
> +BEGIN_FTR_SECTION
> + ld r4,VCPU_PPR(r3)
> + mtspr SPRN_PPR,r4
> +END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> +
> + reg = 4
> + .rept 28
> + ld reg,__VCPU_GPR(reg)(r3)
> + reg = reg + 1
> + .endr
> +
> + ld r4,VCPU_KVM(r3)
> + lbz r4,KVM_SECURE_GUEST(r4)
This does not compile when CONFIG_KVM_BOOK3S_HV_POSSIBLE is not defined.
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
From: Alexey Kardashevskiy @ 2021-04-09 4:36 UTC (permalink / raw)
To: Michael Ellerman, Leonardo Bras, Benjamin Herrenschmidt,
Paul Mackerras, brking
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87ft01du50.fsf@mpe.ellerman.id.au>
On 08/04/2021 19:04, Michael Ellerman wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
>> On 08/04/2021 15:37, Michael Ellerman wrote:
>>> Leonardo Bras <leobras.c@gmail.com> writes:
>>>> According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
>>>> will let the OS know all possible pagesizes that can be used for creating a
>>>> new DDW.
>>>>
>>>> Currently Linux will only try using 3 of the 8 available options:
>>>> 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M,
>>>> 128M, 256M and 16G.
>>>
>>> Do we know of any hardware & hypervisor combination that will actually
>>> give us bigger pages?
>>
>>
>> On P8 16MB host pages and 16MB hardware iommu pages worked.
>>
>> On P9, VM's 16MB IOMMU pages worked on top of 2MB host pages + 2MB
>> hardware IOMMU pages.
>
> The current code already tries 16MB though.
>
> I'm wondering if we're going to ask for larger sizes that have never
> been tested and possibly expose bugs. But it sounds like this is mainly
> targeted at future platforms.
I tried for fun to pass through a PCI device to a guest with this patch as:
pbuild/qemu-killslof-aiku1904le-ppc64/qemu-system-ppc64 \
-nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
-mon id=MON0,chardev=STDIO0,mode=readline \
-nographic \
-vga none \
-enable-kvm \
-m 16G \
-kernel ./vmldbg \
-initrd /home/aik/t/le.cpio \
-device vfio-pci,id=vfio0001_01_00_0,host=0001:01:00.0 \
-mem-prealloc \
-mem-path qemu_hp_1G_node0 \
-global spapr-pci-host-bridge.pgsz=0xffffff000 \
-machine cap-cfpc=broken,cap-ccf-assist=off \
-smp 1,threads=1 \
-L /home/aik/t/qemu-ppc64-bios/ \
-trace events=qemu_trace_events \
-d guest_errors,mmu \
-chardev socket,id=SOCKET0,server=on,wait=off,path=qemu.mon.1_1_0_0 \
-mon chardev=SOCKET0,mode=control
The guest created a huge window:
xhci_hcd 0000:00:00.0: ibm,create-pe-dma-window(2027) 0 8000000 20000000
22 22 returned 0 (liobn = 0x80000001 starting addr = 8000000 0)
The first "22" is page_shift in hex (16GB), the second "22" is
window_shift (so we have 1 TCE).
On the host side the window#1 was created with 1GB pages:
pci 0001:01 : [PE# fd] Setting up window#1
800000000000000..80007ffffffffff pg=40000000
The XHCI seems working. Without the patch 16MB was the maximum.
>
>>>> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
>>>> index 9fc5217f0c8e..6cda1c92597d 100644
>>>> --- a/arch/powerpc/platforms/pseries/iommu.c
>>>> +++ b/arch/powerpc/platforms/pseries/iommu.c
>>>> @@ -53,6 +53,20 @@ enum {
>>>> DDW_EXT_QUERY_OUT_SIZE = 2
>>>> };
>>>
>>> A comment saying where the values come from would be good.
>>>
>>>> +#define QUERY_DDW_PGSIZE_4K 0x01
>>>> +#define QUERY_DDW_PGSIZE_64K 0x02
>>>> +#define QUERY_DDW_PGSIZE_16M 0x04
>>>> +#define QUERY_DDW_PGSIZE_32M 0x08
>>>> +#define QUERY_DDW_PGSIZE_64M 0x10
>>>> +#define QUERY_DDW_PGSIZE_128M 0x20
>>>> +#define QUERY_DDW_PGSIZE_256M 0x40
>>>> +#define QUERY_DDW_PGSIZE_16G 0x80
>>>
>>> I'm not sure the #defines really gain us much vs just putting the
>>> literal values in the array below?
>>
>> Then someone says "uuuuu magic values" :) I do not mind either way. Thanks,
>
> Yeah that's true. But #defining them doesn't make them less magic, if
> you only use them in one place :)
Defining them with "QUERY_DDW" in the names kinda tells where they are
from. Can also grep QEMU using these to see how the other side handles
it. Dunno.
btw the bot complained about __builtin_ctz(SZ_16G) which should be
__builtin_ctzl(SZ_16G) so we have to ask Leonardo to repost anyway :)
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
From: Leonardo Bras @ 2021-04-09 4:44 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, Paul Mackerras, Brian King, linuxppc-dev
In-Reply-To: <21407a96-5b20-3fae-f1c8-895973b655ef@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]
Em sex., 9 de abr. de 2021 01:36, Alexey Kardashevskiy <aik@ozlabs.ru>
escreveu:
>
>
> On 08/04/2021 19:04, Michael Ellerman wrote:
> > Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> >> On 08/04/2021 15:37, Michael Ellerman wrote:
> >>> Leonardo Bras <leobras.c@gmail.com> writes:
> >>>> According to LoPAR, ibm,query-pe-dma-window output named "IO Page
> Sizes"
> >>>> will let the OS know all possible pagesizes that can be used for
> creating a
> >>>> new DDW.
> >>>>
> >>>> Currently Linux will only try using 3 of the 8 available options:
> >>>> 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M,
> 64M,
> >>>> 128M, 256M and 16G.
> >>>
> >>> Do we know of any hardware & hypervisor combination that will actually
> >>> give us bigger pages?
> >>
> >>
> >> On P8 16MB host pages and 16MB hardware iommu pages worked.
> >>
> >> On P9, VM's 16MB IOMMU pages worked on top of 2MB host pages + 2MB
> >> hardware IOMMU pages.
> >
> > The current code already tries 16MB though.
> >
> > I'm wondering if we're going to ask for larger sizes that have never
> > been tested and possibly expose bugs. But it sounds like this is mainly
> > targeted at future platforms.
>
>
> I tried for fun to pass through a PCI device to a guest with this patch as:
>
> pbuild/qemu-killslof-aiku1904le-ppc64/qemu-system-ppc64 \
> -nodefaults \
> -chardev stdio,id=STDIO0,signal=off,mux=on \
> -device spapr-vty,id=svty0,reg=0x71000110,chardev=STDIO0 \
> -mon id=MON0,chardev=STDIO0,mode=readline \
> -nographic \
> -vga none \
> -enable-kvm \
> -m 16G \
> -kernel ./vmldbg \
> -initrd /home/aik/t/le.cpio \
> -device vfio-pci,id=vfio0001_01_00_0,host=0001:01:00.0 \
> -mem-prealloc \
> -mem-path qemu_hp_1G_node0 \
> -global spapr-pci-host-bridge.pgsz=0xffffff000 \
> -machine cap-cfpc=broken,cap-ccf-assist=off \
> -smp 1,threads=1 \
> -L /home/aik/t/qemu-ppc64-bios/ \
> -trace events=qemu_trace_events \
> -d guest_errors,mmu \
> -chardev socket,id=SOCKET0,server=on,wait=off,path=qemu.mon.1_1_0_0 \
> -mon chardev=SOCKET0,mode=control
>
>
> The guest created a huge window:
>
> xhci_hcd 0000:00:00.0: ibm,create-pe-dma-window(2027) 0 8000000 20000000
> 22 22 returned 0 (liobn = 0x80000001 starting addr = 8000000 0)
>
> The first "22" is page_shift in hex (16GB), the second "22" is
> window_shift (so we have 1 TCE).
>
> On the host side the window#1 was created with 1GB pages:
> pci 0001:01 : [PE# fd] Setting up window#1
> 800000000000000..80007ffffffffff pg=40000000
>
>
> The XHCI seems working. Without the patch 16MB was the maximum.
>
>
> >
> >>>> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> >>>> index 9fc5217f0c8e..6cda1c92597d 100644
> >>>> --- a/arch/powerpc/platforms/pseries/iommu.c
> >>>> +++ b/arch/powerpc/platforms/pseries/iommu.c
> >>>> @@ -53,6 +53,20 @@ enum {
> >>>> DDW_EXT_QUERY_OUT_SIZE = 2
> >>>> };
> >>>
> >>> A comment saying where the values come from would be good.
> >>>
> >>>> +#define QUERY_DDW_PGSIZE_4K 0x01
> >>>> +#define QUERY_DDW_PGSIZE_64K 0x02
> >>>> +#define QUERY_DDW_PGSIZE_16M 0x04
> >>>> +#define QUERY_DDW_PGSIZE_32M 0x08
> >>>> +#define QUERY_DDW_PGSIZE_64M 0x10
> >>>> +#define QUERY_DDW_PGSIZE_128M 0x20
> >>>> +#define QUERY_DDW_PGSIZE_256M 0x40
> >>>> +#define QUERY_DDW_PGSIZE_16G 0x80
> >>>
> >>> I'm not sure the #defines really gain us much vs just putting the
> >>> literal values in the array below?
> >>
> >> Then someone says "uuuuu magic values" :) I do not mind either way.
> Thanks,
> >
> > Yeah that's true. But #defining them doesn't make them less magic, if
> > you only use them in one place :)
>
> Defining them with "QUERY_DDW" in the names kinda tells where they are
> from. Can also grep QEMU using these to see how the other side handles
> it. Dunno.
>
> btw the bot complained about __builtin_ctz(SZ_16G) which should be
> __builtin_ctzl(SZ_16G) so we have to ask Leonardo to repost anyway :)
>
Thanks for testing!
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210408201915.174217-1-leobras.c@gmail.com/
I sent a v3 a few hours ago, fixing this by using __builtin_ctzll() instead
of __builtin_ctz() in all sizes, and it worked like a charm.
I also reverted to the previous approach of not having QUERY_DDW defines
for masks, as Michael suggested.
I can revert back to v2 approach if you guys decide it's better.
Best regards,
Leonardo Bras
[-- Attachment #2: Type: text/html, Size: 6576 bytes --]
^ permalink raw reply
* Re: [powerpc:next-test 168/182] include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
From: Christophe Leroy @ 2021-04-09 4:55 UTC (permalink / raw)
To: kernel test robot; +Cc: linuxppc-dev, kbuild-all
In-Reply-To: <202104090827.jH0WBiCC-lkp@intel.com>
Le 09/04/2021 à 02:41, kernel test robot a écrit :
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb
> commit: 093cb12967d4bde01a4170fd342bc0d443004599 [168/182] powerpc/32s: Define a MODULE area below kernel text all the time
> config: powerpc64-randconfig-c004-20210408 (attached as .config)
> compiler: powerpc-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=093cb12967d4bde01a4170fd342bc0d443004599
> git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> git fetch --no-tags powerpc next-test
> git checkout 093cb12967d4bde01a4170fd342bc0d443004599
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> In file included from <command-line>:
> arch/powerpc/kernel/module.c: In function 'module_alloc':
>>> include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
I don't think there is much we can do about that.
TASK_SIZE is set to 0xb0000000 by default on BOOK3S/32 in Kconfig.
If the user forces a greater value without increasing PAGE_OFFSET accordingly, it won't work. The
BUILD_BUG_ON() is there to catch it.
Christophe
^ permalink raw reply
* Re: [powerpc:next-test] BUILD REGRESSION 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb
From: Christophe Leroy @ 2021-04-09 5:01 UTC (permalink / raw)
To: kernel test robot, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <606fbbcd.YCqB+tR1NRgrmWMp%lkp@intel.com>
Le 09/04/2021 à 04:28, kernel test robot a écrit :
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> branch HEAD: 3ac6488df9160f52bbd8b8ec3387a53ac3d0f2eb powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler
>
> Error/Warning reports:
>
> https://lore.kernel.org/linuxppc-dev/202104090230.ACwnO03u-lkp@intel.com
> https://lore.kernel.org/linuxppc-dev/202104090827.jH0WBiCC-lkp@intel.com
>
> Error/Warning in current branch:
>
> include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_171' declared with attribute error: BUILD_BUG_ON failed: TASK_SIZE > MODULES_VADDR
As I pointed in the report, this is because the rand config has set TASK_SIZE to 0xc0000000 without
changing PAGE_OFFSET. Therefore there is no space inbetween for the 256Mbytes segment for modules.
It is too complex to guard this inside the Kconfig, that's the reason why we have a BUILD_BUG_ON().
There was already a similar kind of build test to make sure TASK_SIZE is not greater than KERNEL_START.
>
> Error/Warning ids grouped by kconfigs:
>
> gcc_recent_errors
> |-- powerpc-randconfig-s031-20210408
> | |-- drivers-w1-slaves-w1_ds28e04.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-char-const-noderef-__user-_gu_addr-got-char-const-buf
> | `-- drivers-w1-slaves-w1_ds28e04.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-char-noderef-__user-_pu_addr-got-char-buf
> `-- powerpc64-randconfig-c004-20210408
> `-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:BUILD_BUG_ON-failed:TASK_SIZE-MODULES_VADDR
>
> elapsed time: 727m
>
> configs tested: 166
> configs skipped: 2
>
> gcc tested configs:
> arm defconfig
> arm64 allyesconfig
> arm64 defconfig
> arm allyesconfig
> arm allmodconfig
> x86_64 allyesconfig
> riscv allmodconfig
> riscv allyesconfig
> i386 allyesconfig
> mips rt305x_defconfig
> um allnoconfig
> sh urquell_defconfig
> sh titan_defconfig
> arm ezx_defconfig
> arm oxnas_v6_defconfig
> powerpc akebono_defconfig
> arm eseries_pxa_defconfig
> arm pleb_defconfig
> m68k amcore_defconfig
> sparc sparc32_defconfig
> powerpc ppa8548_defconfig
> x86_64 alldefconfig
> mips maltaup_xpa_defconfig
> xtensa cadence_csp_defconfig
> powerpc allnoconfig
> powerpc mgcoge_defconfig
> powerpc linkstation_defconfig
> sh migor_defconfig
> mips lemote2f_defconfig
> m68k m5407c3_defconfig
> arm lart_defconfig
> arm spitz_defconfig
> arm palmz72_defconfig
> arm lpc32xx_defconfig
> ia64 alldefconfig
> powerpc mpc832x_mds_defconfig
> powerpc ppc6xx_defconfig
> sh sh7770_generic_defconfig
> sh sh2007_defconfig
> mips ip28_defconfig
> sh r7780mp_defconfig
> m68k mvme16x_defconfig
> arm multi_v5_defconfig
> powerpc kmeter1_defconfig
> arc nsimosci_hs_defconfig
> arm clps711x_defconfig
> xtensa xip_kc705_defconfig
> m68k bvme6000_defconfig
> h8300 alldefconfig
> riscv nommu_k210_defconfig
> mips loongson1b_defconfig
> mips decstation_64_defconfig
> powerpc ppc64e_defconfig
> mips rb532_defconfig
> powerpc mpc834x_mds_defconfig
> sh landisk_defconfig
> powerpc arches_defconfig
> m68k hp300_defconfig
> s390 debug_defconfig
> sh kfr2r09-romimage_defconfig
> arm mxs_defconfig
> mips malta_defconfig
> arm u8500_defconfig
> sh se7206_defconfig
> nios2 alldefconfig
> arc vdk_hs38_defconfig
> sh sdk7786_defconfig
> powerpc mpc83xx_defconfig
> arm pxa3xx_defconfig
> um x86_64_defconfig
> arm zeus_defconfig
> arm footbridge_defconfig
> powerpc warp_defconfig
> mips ip22_defconfig
> m68k multi_defconfig
> sh lboxre2_defconfig
> powerpc mpc5200_defconfig
> powerpc ep88xc_defconfig
> m68k amiga_defconfig
> arm colibri_pxa270_defconfig
> arm xcep_defconfig
> ia64 zx1_defconfig
> sh sh7785lcr_32bit_defconfig
> arm dove_defconfig
> powerpc mpc85xx_cds_defconfig
> arm shannon_defconfig
> powerpc xes_mpc85xx_defconfig
> arm at91_dt_defconfig
> sh sh7724_generic_defconfig
> arc vdk_hs38_smp_defconfig
> mips ip32_defconfig
> powerpc mpc8272_ads_defconfig
> openrisc defconfig
> riscv nommu_k210_sdcard_defconfig
> mips ath25_defconfig
> mips ath79_defconfig
> powerpc ps3_defconfig
> arm gemini_defconfig
> arm realview_defconfig
> arm iop32x_defconfig
> ia64 allmodconfig
> ia64 defconfig
> ia64 allyesconfig
> m68k allmodconfig
> m68k defconfig
> m68k allyesconfig
> nios2 defconfig
> arc allyesconfig
> nds32 allnoconfig
> nds32 defconfig
> nios2 allyesconfig
> csky defconfig
> alpha defconfig
> alpha allyesconfig
> xtensa allyesconfig
> h8300 allyesconfig
> arc defconfig
> sh allmodconfig
> parisc defconfig
> s390 allyesconfig
> s390 allmodconfig
> parisc allyesconfig
> s390 defconfig
> sparc allyesconfig
> sparc defconfig
> i386 defconfig
> mips allyesconfig
> mips allmodconfig
> powerpc allyesconfig
> powerpc allmodconfig
> x86_64 randconfig-a004-20210408
> x86_64 randconfig-a005-20210408
> x86_64 randconfig-a003-20210408
> x86_64 randconfig-a001-20210408
> x86_64 randconfig-a002-20210408
> x86_64 randconfig-a006-20210408
> i386 randconfig-a006-20210408
> i386 randconfig-a003-20210408
> i386 randconfig-a001-20210408
> i386 randconfig-a004-20210408
> i386 randconfig-a005-20210408
> i386 randconfig-a002-20210408
> i386 randconfig-a014-20210408
> i386 randconfig-a016-20210408
> i386 randconfig-a011-20210408
> i386 randconfig-a012-20210408
> i386 randconfig-a013-20210408
> i386 randconfig-a015-20210408
> riscv nommu_virt_defconfig
> riscv allnoconfig
> riscv defconfig
> riscv rv32_defconfig
> um allmodconfig
> um allyesconfig
> um defconfig
> x86_64 rhel-8.3-kselftests
> x86_64 defconfig
> x86_64 rhel-8.3
> x86_64 rhel-8.3-kbuiltin
> x86_64 kexec
>
> clang tested configs:
> x86_64 randconfig-a014-20210408
> x86_64 randconfig-a015-20210408
> x86_64 randconfig-a012-20210408
> x86_64 randconfig-a011-20210408
> x86_64 randconfig-a013-20210408
> x86_64 randconfig-a016-20210408
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
^ permalink raw reply
* Re: [PATCH v3 0/9] Speedup mremap on ppc64
From: Aneesh Kumar K.V @ 2021-04-09 5:48 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: joel, linuxppc-dev, npiggin, kaleshsingh
In-Reply-To: <20210330060752.592769-1-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
> the platform to support updating higher-level page tables without
> updating page table entries. This also needs to invalidate the Page Walk
> Cache on architecture supporting the same.
>
> Changes from v2:
> * switch from using mmu_gather to flush_pte_tlb_pwc_range()
>
> Changes from v1:
> * Rebase to recent upstream
> * Fix build issues with tlb_gather_mmu changes
>
Gentle ping. Any objections for this series?
-aneesh
^ permalink raw reply
* Re: [PATCH v1 1/1] kernel.h: Split out panic and oops helpers
From: Andrew Morton @ 2021-04-09 6:23 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Corey Minyard, Linux on Hyper-V List, Tetsuo Handa,
linux-remoteproc, Michael Kelley, Paul Mackerras, H. Peter Anvin,
Joel Fernandes, K. Y. Srinivasan, Thomas Gleixner, Linux-Arch,
Wei Liu, Andy Shevchenko, Stephen Hemminger, Corey Minyard,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Ingo Molnar,
Iurii Zaikin, Ohad Ben-Cohen, Joerg Roedel, Kees Cook,
Paul E. McKenney, Lai Jiangshan, Haiyang Zhang, Josh Triplett,
Steven Rostedt (VMware), rcu, Borislav Petkov, openipmi-developer,
Bjorn Andersson, Vlastimil Babka, Mathieu Poirier, kexec,
Linux Kernel Mailing List, Luis Chamberlain, Arnd Bergmann,
Eric Biederman, Linux FS Devel, Mathieu Desnoyers,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Mike Rapoport
In-Reply-To: <CAHp75Ve+11u=dtNTO8BCohOJHGWSMJtb1nGCOrNde7bXaD4ehA@mail.gmail.com>
On Wed, 7 Apr 2021 11:46:37 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Wed, Apr 7, 2021 at 11:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > > Here is the attempt to start cleaning it up by splitting out panic and
> > > oops helpers.
> > >
> > > At the same time convert users in header and lib folder to use new header.
> > > Though for time being include new header back to kernel.h to avoid twisted
> > > indirected includes for existing users.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > I like it! Do you have a multi-arch CI to do allmodconfig builds to
> > double-check this?
>
> Unfortunately no, I rely on plenty of bots that are harvesting mailing lists.
>
> But I will appreciate it if somebody can run this through various build tests.
>
um, did you try x86_64 allmodconfig?
I'm up to
kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix.patch
and counting.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix
more files need panic_notifier.h
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/xen/enlighten.c | 1 +
drivers/video/fbdev/hyperv_fb.c | 1 +
2 files changed, 2 insertions(+)
--- a/arch/x86/xen/enlighten.c~kernelh-split-out-panic-and-oops-helpers-fix
+++ a/arch/x86/xen/enlighten.c
@@ -6,6 +6,7 @@
#include <linux/cpu.h>
#include <linux/kexec.h>
#include <linux/slab.h>
+#include <linux/panic_notifier.h>
#include <xen/xen.h>
#include <xen/features.h>
--- a/drivers/video/fbdev/hyperv_fb.c~kernelh-split-out-panic-and-oops-helpers-fix
+++ a/drivers/video/fbdev/hyperv_fb.c
@@ -52,6 +52,7 @@
#include <linux/completion.h>
#include <linux/fb.h>
#include <linux/pci.h>
+#include <linux/panic_notifier.h>
#include <linux/efi.h>
#include <linux/console.h>
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix
arch/x86/purgatory/purgatory.c needs kernel.h
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/purgatory/purgatory.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/purgatory/purgatory.c~kernelh-split-out-panic-and-oops-helpers-fix-fix
+++ a/arch/x86/purgatory/purgatory.c
@@ -8,6 +8,7 @@
* Vivek Goyal <vgoyal@redhat.com>
*/
+#include <linux/kernel.h>
#include <linux/bug.h>
#include <crypto/sha2.h>
#include <asm/purgatory.h>
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix-fix
drivers/clk/analogbits/wrpll-cln28hpc.c needs minmax.h, math.h and limits.h
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/clk/analogbits/wrpll-cln28hpc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/clk/analogbits/wrpll-cln28hpc.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix
+++ a/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -25,6 +25,10 @@
#include <linux/err.h>
#include <linux/log2.h>
#include <linux/math64.h>
+#include <linux/minmax.h>
+#include <linux/math.h>
+#include <linux/limits.h>
+
#include <linux/clk/analogbits-wrpll-cln28hpc.h>
/* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix
drivers/misc/pvpanic/pvpanic.c needs panic_notifier.h
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/misc/pvpanic/pvpanic.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/misc/pvpanic/pvpanic.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix
+++ a/drivers/misc/pvpanic/pvpanic.c
@@ -13,6 +13,7 @@
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/panic_notifier.h>
#include <linux/types.h>
#include <linux/cdev.h>
#include <linux/list.h>
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix
fix drivers/misc/pvpanic/pvpanic.c and drivers/net/ipa/ipa_smp2p.c
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/ipa/ipa_smp2p.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ipa/ipa_smp2p.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix
+++ a/drivers/net/ipa/ipa_smp2p.c
@@ -8,6 +8,7 @@
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/notifier.h>
+#include <linux/panic_notifier.h>
#include <linux/soc/qcom/smem.h>
#include <linux/soc/qcom/smem_state.h>
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix
fix drivers/power/reset/ltc2952-poweroff.c and drivers/misc/bcm-vk/bcm_vk_dev.c
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/misc/bcm-vk/bcm_vk_dev.c | 1 +
drivers/power/reset/ltc2952-poweroff.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/power/reset/ltc2952-poweroff.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix
+++ a/drivers/power/reset/ltc2952-poweroff.c
@@ -52,6 +52,7 @@
#include <linux/slab.h>
#include <linux/kmod.h>
#include <linux/module.h>
+#include <linux/panic_notifier.h>
#include <linux/mod_devicetable.h>
#include <linux/gpio/consumer.h>
#include <linux/reboot.h>
--- a/drivers/misc/bcm-vk/bcm_vk_dev.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix
+++ a/drivers/misc/bcm-vk/bcm_vk_dev.c
@@ -9,6 +9,7 @@
#include <linux/fs.h>
#include <linux/idr.h>
#include <linux/interrupt.h>
+#include <linux/panic_notifier.h>
#include <linux/kref.h>
#include <linux/module.h>
#include <linux/mutex.h>
_
From: Andrew Morton <akpm@linux-foundation.org>
Subject: kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix
fix drivers/leds/trigger/ledtrig-panic.c and drivers/firmware/google/gsmi.c
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/firmware/google/gsmi.c | 1 +
drivers/leds/trigger/ledtrig-panic.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/leds/trigger/ledtrig-panic.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix
+++ a/drivers/leds/trigger/ledtrig-panic.c
@@ -8,6 +8,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/notifier.h>
+#include <linux/panic_notifier.h>
#include <linux/leds.h>
#include "../leds.h"
--- a/drivers/firmware/google/gsmi.c~kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix
+++ a/drivers/firmware/google/gsmi.c
@@ -19,6 +19,7 @@
#include <linux/dma-mapping.h>
#include <linux/fs.h>
#include <linux/slab.h>
+#include <linux/panic_notifier.h>
#include <linux/ioctl.h>
#include <linux/acpi.h>
#include <linux/io.h>
_
and.... drivers/leds/trigger/ledtrig-heartbeat.c as well.
I'll drop it.
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd DAWR
From: Daniel Axtens @ 2021-04-09 6:52 UTC (permalink / raw)
To: Ravi Bangoria, mpe
Cc: ravi.bangoria, mikey, shuah, linuxppc-dev, linux-kselftest
In-Reply-To: <20210407054938.312857-2-ravi.bangoria@linux.ibm.com>
Hi Ravi,
> Add selftests to test multiple active DAWRs with ptrace interface.
It would be good if somewhere (maybe in the cover letter) you explain
what DAWR stands for and where to find more information about it. I
found the Power ISA v3.1 Book 3 Chapter 9 very helpful.
Apart from that, I don't have any specific comments about this patch. It
looks good to me, it seems to do what it says, and there are no comments
from checkpatch. It is a bit sparse in terms of comments but it is
consistent with the rest of the file so I can't really complain there :)
Reviewed-by: Daniel Axtens <dja@axtens.net>
Kind regards,
Daniel
> Sample o/p:
> $ ./ptrace-hwbreak
> ...
> PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW UNALIGNED, RO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, WO, len: 6: Ok
> PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, RO, len: 6: Ok
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> .../selftests/powerpc/ptrace/ptrace-hwbreak.c | 79 +++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
> index 2e0d86e0687e..a0635a3819aa 100644
> --- a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
> +++ b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
> @@ -194,6 +194,18 @@ static void test_workload(void)
> big_var[rand() % DAWR_MAX_LEN] = 'a';
> else
> cvar = big_var[rand() % DAWR_MAX_LEN];
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW ALIGNED, WO test */
> + gstruct.a[rand() % A_LEN] = 'a';
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW UNALIGNED, RO test */
> + cvar = gstruct.b[rand() % B_LEN];
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, WO test */
> + gstruct.a[rand() % A_LEN] = 'a';
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, RO test */
> + cvar = gstruct.a[rand() % A_LEN];
> }
>
> static void check_success(pid_t child_pid, const char *name, const char *type,
> @@ -417,6 +429,69 @@ static void test_sethwdebug_range_aligned(pid_t child_pid)
> ptrace_delhwdebug(child_pid, wh);
> }
>
> +static void test_multi_sethwdebug_range(pid_t child_pid)
> +{
> + struct ppc_hw_breakpoint info1, info2;
> + unsigned long wp_addr1, wp_addr2;
> + char *name1 = "PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW ALIGNED";
> + char *name2 = "PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW UNALIGNED";
> + int len1, len2;
> + int wh1, wh2;
> +
> + wp_addr1 = (unsigned long)&gstruct.a;
> + wp_addr2 = (unsigned long)&gstruct.b;
> + len1 = A_LEN;
> + len2 = B_LEN;
> + get_ppc_hw_breakpoint(&info1, PPC_BREAKPOINT_TRIGGER_WRITE, wp_addr1, len1);
> + get_ppc_hw_breakpoint(&info2, PPC_BREAKPOINT_TRIGGER_READ, wp_addr2, len2);
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW ALIGNED, WO test */
> + wh1 = ptrace_sethwdebug(child_pid, &info1);
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DW UNALIGNED, RO test */
> + wh2 = ptrace_sethwdebug(child_pid, &info2);
> +
> + ptrace(PTRACE_CONT, child_pid, NULL, 0);
> + check_success(child_pid, name1, "WO", wp_addr1, len1);
> +
> + ptrace(PTRACE_CONT, child_pid, NULL, 0);
> + check_success(child_pid, name2, "RO", wp_addr2, len2);
> +
> + ptrace_delhwdebug(child_pid, wh1);
> + ptrace_delhwdebug(child_pid, wh2);
> +}
> +
> +static void test_multi_sethwdebug_range_dawr_overlap(pid_t child_pid)
> +{
> + struct ppc_hw_breakpoint info1, info2;
> + unsigned long wp_addr1, wp_addr2;
> + char *name = "PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap";
> + int len1, len2;
> + int wh1, wh2;
> +
> + wp_addr1 = (unsigned long)&gstruct.a;
> + wp_addr2 = (unsigned long)&gstruct.a;
> + len1 = A_LEN;
> + len2 = A_LEN;
> + get_ppc_hw_breakpoint(&info1, PPC_BREAKPOINT_TRIGGER_WRITE, wp_addr1, len1);
> + get_ppc_hw_breakpoint(&info2, PPC_BREAKPOINT_TRIGGER_READ, wp_addr2, len2);
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, WO test */
> + wh1 = ptrace_sethwdebug(child_pid, &info1);
> +
> + /* PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, RO test */
> + wh2 = ptrace_sethwdebug(child_pid, &info2);
> +
> + ptrace(PTRACE_CONT, child_pid, NULL, 0);
> + check_success(child_pid, name, "WO", wp_addr1, len1);
> +
> + ptrace(PTRACE_CONT, child_pid, NULL, 0);
> + check_success(child_pid, name, "RO", wp_addr2, len2);
> +
> + ptrace_delhwdebug(child_pid, wh1);
> + ptrace_delhwdebug(child_pid, wh2);
> +}
> +
> static void test_sethwdebug_range_unaligned(pid_t child_pid)
> {
> struct ppc_hw_breakpoint info;
> @@ -504,6 +579,10 @@ run_tests(pid_t child_pid, struct ppc_debug_info *dbginfo, bool dawr)
> test_sethwdebug_range_unaligned(child_pid);
> test_sethwdebug_range_unaligned_dar(child_pid);
> test_sethwdebug_dawr_max_range(child_pid);
> + if (dbginfo->num_data_bps > 1) {
> + test_multi_sethwdebug_range(child_pid);
> + test_multi_sethwdebug_range_dawr_overlap(child_pid);
> + }
> }
> }
> }
> --
> 2.27.0
^ permalink raw reply
* [PATCH -next] powerpc/xmon: Make symbol 'spu_inst_dump' static
From: Pu Lehui @ 2021-04-09 7:01 UTC (permalink / raw)
To: mpe, benh, paulus, jniethe5, alistair, ravi.bangoria, pmladek,
john.ogness, npiggin, christophe.leroy, rppt, maddy
Cc: zhangjinhao2, yangjihong1, linuxppc-dev, linux-kernel, pulehui
Fix sparse warning:
arch/powerpc/xmon/xmon.c:4216:1: warning:
symbol 'spu_inst_dump' was not declared. Should it be static?
This symbol is not used outside of xmon.c, so make it static.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
arch/powerpc/xmon/xmon.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index bf7d69625a2e..d4ae2a25781f 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -4212,8 +4212,7 @@ static void dump_spu_fields(struct spu *spu)
DUMP_FIELD(spu, "0x%p", pdata);
}
-int
-spu_inst_dump(unsigned long adr, long count, int praddr)
+static int spu_inst_dump(unsigned long adr, long count, int praddr)
{
return generic_inst_dump(adr, count, praddr, print_insn_spu);
}
--
2.17.1
^ permalink raw reply related
* [PATCH -next] powerpc/powernv: make symbol 'mpipl_kobj' static
From: Bixuan Cui @ 2021-04-09 6:38 UTC (permalink / raw)
To: cuibixuan, Michael Ellerman, Qinglang Miao, Al Viro
Cc: kernel-janitors, linuxppc-dev, linux-kernel
The sparse tool complains as follows:
arch/powerpc/platforms/powernv/opal-core.c:74:16: warning:
symbol 'mpipl_kobj' was not declared.
This symbol is not used outside of opal-core.c, so marks it static.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
---
arch/powerpc/platforms/powernv/opal-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-core.c b/arch/powerpc/platforms/powernv/opal-core.c
index 0d9ba70f7251..5b9736bbc2aa 100644
--- a/arch/powerpc/platforms/powernv/opal-core.c
+++ b/arch/powerpc/platforms/powernv/opal-core.c
@@ -71,7 +71,7 @@ static LIST_HEAD(opalcore_list);
static struct opalcore_config *oc_conf;
static const struct opal_mpipl_fadump *opalc_metadata;
static const struct opal_mpipl_fadump *opalc_cpu_metadata;
-struct kobject *mpipl_kobj;
+static struct kobject *mpipl_kobj;
/*
* Set crashing CPU's signal to SIGUSR1. if the kernel is triggered
^ permalink raw reply related
* Re: [PATCH v2 2/4] powerpc/selftests/perf-hwbreak: Coalesce event creation code
From: Daniel Axtens @ 2021-04-09 7:19 UTC (permalink / raw)
To: Ravi Bangoria, mpe
Cc: ravi.bangoria, mikey, shuah, linuxppc-dev, linux-kselftest
In-Reply-To: <20210407054938.312857-3-ravi.bangoria@linux.ibm.com>
Hi Ravi,
> perf-hwbreak selftest opens hw-breakpoint event at multiple places for
> which it has same code repeated. Coalesce that code into a function.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> .../selftests/powerpc/ptrace/perf-hwbreak.c | 78 +++++++++----------
This doesn't simplify things very much for the code as it stands now,
but I think your next patch adds a bunch of calls to these functions, so
I agree that it makes sense to consolidate them now.
> 1 file changed, 38 insertions(+), 40 deletions(-)
>
> diff --git a/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c b/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
> index c1f324afdbf3..bde475341c8a 100644
> --- a/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
> +++ b/tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c
> @@ -34,28 +34,46 @@
>
> #define DAWR_LENGTH_MAX ((0x3f + 1) * 8)
>
> -static inline int sys_perf_event_open(struct perf_event_attr *attr, pid_t pid,
> - int cpu, int group_fd,
> - unsigned long flags)
> +static void perf_event_attr_set(struct perf_event_attr *attr,
> + __u32 type, __u64 addr, __u64 len,
> + bool exclude_user)
> {
> - attr->size = sizeof(*attr);
> - return syscall(__NR_perf_event_open, attr, pid, cpu, group_fd, flags);
> + memset(attr, 0, sizeof(struct perf_event_attr));
> + attr->type = PERF_TYPE_BREAKPOINT;
> + attr->size = sizeof(struct perf_event_attr);
> + attr->bp_type = type;
> + attr->bp_addr = addr;
> + attr->bp_len = len;
> + attr->exclude_kernel = 1;
> + attr->exclude_hv = 1;
> + attr->exclude_guest = 1;
Only 1 of the calls to perf sets exclude_{kernel,hv,guest} - I assume
there's no issue with setting them always but I wanted to check.
> + attr->exclude_user = exclude_user;
> + attr->disabled = 1;
> }
>
> - /* setup counters */
> - memset(&attr, 0, sizeof(attr));
> - attr.disabled = 1;
> - attr.type = PERF_TYPE_BREAKPOINT;
> - attr.bp_type = readwriteflag;
> - attr.bp_addr = (__u64)ptr;
> - attr.bp_len = sizeof(int);
> - if (arraytest)
> - attr.bp_len = DAWR_LENGTH_MAX;
> - attr.exclude_user = exclude_user;
> - break_fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
> + break_fd = perf_process_event_open_exclude_user(readwriteflag, (__u64)ptr,
> + arraytest ? DAWR_LENGTH_MAX : sizeof(int),
> + exclude_user);
checkpatch doesn't like this very much:
CHECK: Alignment should match open parenthesis
#103: FILE: tools/testing/selftests/powerpc/ptrace/perf-hwbreak.c:115:
+ break_fd = perf_process_event_open_exclude_user(readwriteflag, (__u64)ptr,
+ arraytest ? DAWR_LENGTH_MAX : sizeof(int),
Apart from that, this seems good but I haven't checked in super fine
detail just yet :)
Kind regards,
Daniel
^ permalink raw reply
* Re: [PATCH] powerpc/dts: fix not include DTC_FLAGS
From: Sam Song @ 2021-04-09 7:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: devicetree, linux-kernel, robh+dt, paulus, linuxppc-dev
In-Reply-To: <87y2due3mt.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
In my test, DTC_FLAGS in arch/powerpc/boot/Makefile is not to work,I will
send V2 to removing it.
Michael Ellerman <mpe@ellerman.id.au> 于2021年4月7日周三 下午7:27写道：
> Youlin Song <syl.loop@gmail.com> writes:
> > I wanted to build the fsl dts in my machine and found that
> > the dtb have not extra space,so uboot will cause about
> > FDT_ERR_NOSPACE issue.
> >
> > Signed-off-by: Youlin Song <syl.loop@gmail.com>
> > ---
> > arch/powerpc/boot/dts/Makefile | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/powerpc/boot/dts/Makefile
> b/arch/powerpc/boot/dts/Makefile
> > index fb335d05aae8..c21165c0cd76 100644
> > --- a/arch/powerpc/boot/dts/Makefile
> > +++ b/arch/powerpc/boot/dts/Makefile
> > @@ -2,5 +2,6 @@
> >
> > subdir-y += fsl
> >
> > +DTC_FLAGS ?= -p 1024
> > dtstree := $(srctree)/$(src)
> > dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb,
> $(wildcard $(dtstree)/*.dts))
>
> I guess that was missed in 1acf1cf8638a ("powerpc: build .dtb files in dts
> directory").
>
> Which I think means the assignment to DTC_FLAGS in
> arch/powerpc/boot/Makefile is not needed anymore.
>
> Can you send a v2 removing that assignment and explaining that's what
> happened?
>
> cheers
>
[-- Attachment #2: Type: text/html, Size: 1848 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/1] kernel.h: Split out panic and oops helpers
From: Andy Shevchenko @ 2021-04-09 8:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Corey Minyard, Linux on Hyper-V List, Tetsuo Handa,
linux-remoteproc, Michael Kelley, Paul Mackerras, H. Peter Anvin,
Joel Fernandes, K. Y. Srinivasan, Thomas Gleixner, Linux-Arch,
Wei Liu, Stephen Hemminger, Corey Minyard,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Ingo Molnar,
Iurii Zaikin, Ohad Ben-Cohen, Joerg Roedel, Kees Cook,
Paul E. McKenney, Lai Jiangshan, Haiyang Zhang, Josh Triplett,
Steven Rostedt (VMware), rcu, Borislav Petkov, openipmi-developer,
Bjorn Andersson, Vlastimil Babka, Mathieu Poirier, kexec,
Linux Kernel Mailing List, Luis Chamberlain, Arnd Bergmann,
Eric Biederman, Linux FS Devel, Mathieu Desnoyers,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Mike Rapoport
In-Reply-To: <20210408232303.453749e0e6fb0adfa8545440@linux-foundation.org>
On Thu, Apr 08, 2021 at 11:23:03PM -0700, Andrew Morton wrote:
> On Wed, 7 Apr 2021 11:46:37 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> > On Wed, Apr 7, 2021 at 11:17 AM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > > > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > > > Here is the attempt to start cleaning it up by splitting out panic and
> > > > oops helpers.
> > > >
> > > > At the same time convert users in header and lib folder to use new header.
> > > > Though for time being include new header back to kernel.h to avoid twisted
> > > > indirected includes for existing users.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > >
> > > I like it! Do you have a multi-arch CI to do allmodconfig builds to
> > > double-check this?
> >
> > Unfortunately no, I rely on plenty of bots that are harvesting mailing lists.
> >
> > But I will appreciate it if somebody can run this through various build tests.
> >
>
> um, did you try x86_64 allmodconfig?
>
> I'm up to
> kernelh-split-out-panic-and-oops-helpers-fix-fix-fix-fix-fix-fix-fix.patch
> and counting.
I will try on my side and will fix those, thanks!
> and.... drivers/leds/trigger/ledtrig-heartbeat.c as well.
>
> I'll drop it.
No problem, thanks for the report.
--
With Best Regards,
Andy Shevchenko
^ 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