* Re: [PATCH 0/9] lib/bitmap: optimize bitmap_weight() usage
From: mirq-test @ 2021-11-28 18:03 UTC (permalink / raw)
To: Yury Norov
Cc: Juri Lelli, Andrew Lunn, Rafael J. Wysocki, Catalin Marinas,
Guo Ren, Christoph Lameter, Christoph Hellwig, Andi Kleen,
Vincent Guittot, Ingo Molnar, Geert Uytterhoeven, Mel Gorman,
Viresh Kumar, Petr Mladek, Arnaldo Carvalho de Melo, Jens Axboe,
Andy Lutomirski, Lee Jones, Greg Kroah-Hartman, Randy Dunlap,
linux-kernel, linux-perf-users, Sergey Senozhatsky,
Thomas Gleixner, linux-crypto, Tejun Heo, Andrew Morton,
Mark Rutland, Anup Patel, linux-ia64, David Airlie, Roy Pledge,
Dave Hansen, Solomon Peachy, Stephen Rothwell,
Krzysztof Kozlowski, Dennis Zhou, Matti Vaittinen, linux-alpha,
Kalle Valo, Stephen Boyd, Tariq Toukan, Dinh Nguyen,
Jonathan Cameron, Ulf Hansson, Alexander Shishkin,
Mike Marciniszyn, Rasmus Villemoes, Subbaraya Sundeep,
Will Deacon, Sagi Grimberg, linux-csky, bcm-kernel-feedback-list,
linux-arm-kernel, linux-snps-arc, Kees Cook, Arnd Bergmann,
James E.J. Bottomley, Vineet Gupta, Steven Rostedt, Mark Gross,
Borislav Petkov, Mauro Carvalho Chehab, Thomas Bogendoerfer,
Martin K. Petersen, David Laight, Sudeep Holla, Geetha sowjanya,
Ian Rogers, kvm, Peter Zijlstra, Amitkumar Karwar, linux-mm,
linux-riscv, Jiri Olsa, Ard Biesheuvel, Marc Zyngier,
Russell King, Andy Gross, Jakub Kicinski, Vivien Didelot,
Sunil Goutham, Paul E. McKenney, linux-s390, Alexey Klimov,
Heiko Carstens, Hans de Goede, Nicholas Piggin, Marcin Wojtas,
Vlastimil Babka, linuxppc-dev, linux-mips, Palmer Dabbelt,
Daniel Vetter, Jason Wessel, Saeed Mahameed, Andy Shevchenko
In-Reply-To: <20211128035704.270739-1-yury.norov@gmail.com>
On Sat, Nov 27, 2021 at 07:56:55PM -0800, Yury Norov wrote:
> In many cases people use bitmap_weight()-based functions like this:
>
> if (num_present_cpus() > 1)
> do_something();
>
> This may take considerable amount of time on many-cpus machines because
> num_present_cpus() will traverse every word of underlying cpumask
> unconditionally.
>
> We can significantly improve on it for many real cases if stop traversing
> the mask as soon as we count present cpus to any number greater than 1:
>
> if (num_present_cpus_gt(1))
> do_something();
>
> To implement this idea, the series adds bitmap_weight_{eq,gt,le}
> functions together with corresponding wrappers in cpumask and nodemask.
Having slept on it I have more structured thoughts:
First, I like substituting bitmap_empty/full where possible - I think
the change stands on its own, so could be split and sent as is.
I don't like the proposed API very much. One problem is that it hides
the comparison operator and makes call sites less readable:
bitmap_weight(...) > N
becomes:
bitmap_weight_gt(..., N)
and:
bitmap_weight(...) <= N
becomes:
bitmap_weight_lt(..., N+1)
or:
!bitmap_weight_gt(..., N)
I'd rather see something resembling memcmp() API that's known enough
to be easier to grasp. For above examples:
bitmap_weight_cmp(..., N) > 0
bitmap_weight_cmp(..., N) <= 0
...
This would also make the implementation easier in not having to
copy and paste the code three times. Could also use a simple
optimization reducing code size:
#include <linux/overflow.h>
int bitmap_weight_cmp(long *bits, size_t nbits, size_t cmp)
{
for (size_t i = 0; i < nbits / BITS_PER_LONG; ++i, ++bits)
if (check_sub_overflow(cmp, popcount(*bits), &cmp))
return 1;
nbits %= BITS_PER_LONG;
if (nbits && check_sub_overflow(cmp,
popcount(*bits & GENMASK(nbits)), &cmp))
return 1;
return cmp ? -1 : 0;
}
Best Regards
Michał Mirosław
^ permalink raw reply
* Re: [PATCH 7/9] lib/cpumask: add num_{possible,present,active}_cpus_{eq,gt,le}
From: Yury Norov @ 2021-11-28 18:47 UTC (permalink / raw)
To: Dennis Zhou
Cc: Juri Lelli, Andrew Lunn, Rafael J. Wysocki, Catalin Marinas,
Guo Ren, Christoph Lameter, Christoph Hellwig, Andi Kleen,
Vincent Guittot, Ingo Molnar, Geert Uytterhoeven, Mel Gorman,
Viresh Kumar, Petr Mladek, Arnaldo Carvalho de Melo, Jens Axboe,
Andy Lutomirski, Lee Jones, Greg Kroah-Hartman, Randy Dunlap,
linux-kernel, linux-perf-users, Sergey Senozhatsky,
Thomas Gleixner, linux-crypto, Joe Perches, Andrew Morton,
Mark Rutland, Anup Patel, linux-ia64, David Airlie, Roy Pledge,
Dave Hansen, Solomon Peachy, Stephen Rothwell,
Krzysztof Kozlowski, Matti Vaittinen, linux-alpha, Tejun Heo,
Kalle Valo, Stephen Boyd, Tariq Toukan, Dinh Nguyen,
Jonathan Cameron, Ulf Hansson, Alexander Shishkin,
Mike Marciniszyn, Rasmus Villemoes, Subbaraya Sundeep,
Will Deacon, Sagi Grimberg, linux-csky, bcm-kernel-feedback-list,
linux-arm-kernel, linux-snps-arc, Kees Cook, Arnd Bergmann,
James E.J. Bottomley, Vineet Gupta, Steven Rostedt, Mark Gross,
Borislav Petkov, Mauro Carvalho Chehab, Thomas Bogendoerfer,
Martin K. Petersen, David Laight, Sudeep Holla, Geetha sowjanya,
Ian Rogers, kvm, Peter Zijlstra, Amitkumar Karwar, linux-mm,
linux-riscv, Jiri Olsa, Ard Biesheuvel, Marc Zyngier,
Russell King, Andy Gross, Jakub Kicinski, Vivien Didelot,
Sunil Goutham, Paul E. McKenney, linux-s390, Alexey Klimov,
Heiko Carstens, Hans de Goede, Nicholas Piggin, Marcin Wojtas,
Vlastimil Babka, linuxppc-dev, linux-mips, Palmer Dabbelt,
Daniel Vetter, Jason Wessel, Saeed Mahameed, Andy Shevchenko
In-Reply-To: <YaPCOPqpI/oKrTXl@fedora>
On Sun, Nov 28, 2021 at 12:54:00PM -0500, Dennis Zhou wrote:
> Hello,
>
> On Sun, Nov 28, 2021 at 09:43:20AM -0800, Yury Norov wrote:
> > On Sun, Nov 28, 2021 at 09:07:52AM -0800, Joe Perches wrote:
> > > On Sat, 2021-11-27 at 19:57 -0800, Yury Norov wrote:
> > > > Add num_{possible,present,active}_cpus_{eq,gt,le} and replace num_*_cpus()
> > > > with one of new functions where appropriate. This allows num_*_cpus_*()
> > > > to return earlier depending on the condition.
> > > []
> > > > diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
> > > []
> > > > @@ -103,7 +103,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> > > > * if platform didn't set the present map already, do it now
> > > > * boot cpu is set to present already by init/main.c
> > > > */
> > > > - if (num_present_cpus() <= 1)
> > > > + if (num_present_cpus_le(2))
> > > > init_cpu_present(cpu_possible_mask);
> > >
> > > ? is this supposed to be 2 or 1
> >
> > X <= 1 is the equivalent of X < 2.
> >
> > > > diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
> > > []
> > > > @@ -593,7 +593,7 @@ static int __init pcc_cpufreq_init(void)
> > > > return ret;
> > > > }
> > > >
> > > > - if (num_present_cpus() > 4) {
> > > > + if (num_present_cpus_gt(4)) {
> > > > pcc_cpufreq_driver.flags |= CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING;
> > > > pr_err("%s: Too many CPUs, dynamic performance scaling disabled\n",
> > > > __func__);
> > >
> > > It looks as if the present variants should be using the same values
> > > so the _le test above with 1 changed to 2 looks odd.
> >
>
> I think the confusion comes from le meaning less than rather than lt.
> Given the general convention of: lt (<), le (<=), eg (=), ge (>=),
> gt (>), I'd consider renaming your le to lt.
Ok, makes sense. I'll rename in v2 and add <= and >= versions.
^ permalink raw reply
* Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API
From: Dmitry Osipenko @ 2021-11-28 21:04 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <YaLQqks8cB0vWp6Q@qmqm.qmqm.pl>
28.11.2021 03:43, Michał Mirosław пишет:
> On Fri, Nov 26, 2021 at 09:00:44PM +0300, Dmitry Osipenko wrote:
>> SoC platforms often have multiple ways of how to perform system's
>> power-off and restart operations. Meanwhile today's kernel is limited to
>> a single option. Add combined power-off+restart handler call chain API,
>> which is inspired by the restart API. The new API provides both power-off
>> and restart functionality.
>>
>> The old pm_power_off method will be kept around till all users are
>> converted to the new API.
>>
>> Current restart API will be replaced by the new unified API since
>> new API is its superset. The restart functionality of the sys-off handler
>> API is built upon the existing restart-notifier APIs.
>>
>> In order to ease conversion to the new API, convenient helpers are added
>> for the common use-cases. They will reduce amount of boilerplate code and
>> remove global variables. These helpers preserve old behaviour for cases
>> where only one power-off handler is expected, this is what all existing
>> drivers want, and thus, they could be easily converted to the new API.
>> Users of the new API should explicitly enable power-off chaining by
>> setting corresponding flag of the power_handler structure.
> [...]
>
> Hi,
>
> A general question: do we really need three distinct chains for this?
Hello Michał,
At minimum this makes code easier to follow.
> Can't there be only one that chain of callbacks that get a stage
> (RESTART_PREPARE, RESTART, POWER_OFF_PREPARE, POWER_OFF) and can ignore
> them at will? Calling through POWER_OFF_PREPARE would also return
> whether that POWER_OFF is possible (for kernel_can_power_off()).
I'm having trouble with parsing this comment. Could you please try to
rephrase it? I don't see how you could check whether power-off handler
is available if you'll mix all handlers together.
> I would also split this patch into preparation cleanups (like wrapping
> pm_power_off call with a function) and adding the notifier-based
> implementation.
What's the benefit of this split up will be? Are you suggesting that it
will ease reviewing of this patch or something else?
^ permalink raw reply
* Re: [PATCH v4 22/25] memory: emif: Use kernel_can_power_off()
From: Dmitry Osipenko @ 2021-11-28 21:04 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <YaLaH3Yt2M/Gko//@qmqm.qmqm.pl>
28.11.2021 04:23, Michał Mirosław пишет:
> On Fri, Nov 26, 2021 at 09:00:58PM +0300, Dmitry Osipenko wrote:
>> Replace legacy pm_power_off with kernel_can_power_off() helper that
>> is aware about chained power-off handlers.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> drivers/memory/emif.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
>> index 762d0c0f0716..cab10d5274a0 100644
>> --- a/drivers/memory/emif.c
>> +++ b/drivers/memory/emif.c
>> @@ -630,7 +630,7 @@ static irqreturn_t emif_threaded_isr(int irq, void *dev_id)
>> dev_emerg(emif->dev, "SDRAM temperature exceeds operating limit.. Needs shut down!!!\n");
>>
>> /* If we have Power OFF ability, use it, else try restarting */
>> - if (pm_power_off) {
>> + if (kernel_can_power_off()) {
>> kernel_power_off();
>> } else {
>> WARN(1, "FIXME: NO pm_power_off!!! trying restart\n");
>
> BTW, this part of the code seems to be better moved to generic code that
> could replace POWER_OFF request with REBOOT like it is done for reboot()
> syscall.
Not sure that it can be done. Somebody will have to verify that it won't
break all those platform power-off handlers. Better to keep this code
as-is in the context of this patchset.
^ permalink raw reply
* Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
From: Dmitry Osipenko @ 2021-11-28 21:06 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <YaLNOJTM+lVq+YNS@qmqm.qmqm.pl>
28.11.2021 03:28, Michał Mirosław пишет:
> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
>> Add sanity check which ensures that there are no two restart handlers
>> registered with the same priority. Normally it's a direct sign of a
>> problem if two handlers use the same priority.
>
> The patch doesn't ensure the property that there are no duplicated-priority
> entries on the chain.
It's not the exact point of this patch.
> I'd rather see a atomic_notifier_chain_register_unique() that returns
> -EBUSY or something istead of adding an entry with duplicate priority.
> That way it would need only one list traversal unless you want to
> register the duplicate anyway (then you would call the older
> atomic_notifier_chain_register() after reporting the error).
The point of this patch is to warn developers about the problem that
needs to be fixed. We already have such troubling drivers in mainline.
It's not critical to register different handlers with a duplicated
priorities, but such cases really need to be corrected. We shouldn't
break users' machines during transition to the new API, meanwhile
developers should take action of fixing theirs drivers.
> (Or you could return > 0 when a duplicate is registered in
> atomic_notifier_chain_register() if the callers are prepared
> for that. I don't really like this way, though.)
I had a similar thought at some point before and decided that I'm not in
favor of this approach. It's nicer to have a dedicated function that
verifies the uniqueness, IMO.
^ permalink raw reply
* Re: [PATCH v4 18/25] x86: Use do_kernel_power_off()
From: Dmitry Osipenko @ 2021-11-28 21:06 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <YaLYR24XRijSmBq3@qmqm.qmqm.pl>
28.11.2021 04:15, Michał Mirosław пишет:
> On Fri, Nov 26, 2021 at 09:00:54PM +0300, Dmitry Osipenko wrote:
>> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
>> that invokes chained power-off handlers. It also invokes legacy
>> pm_power_off() for now, which will be removed once all drivers will
>> be converted to the new power-off API.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> arch/x86/kernel/reboot.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>> index 0a40df66a40d..cd7d9416d81a 100644
>> --- a/arch/x86/kernel/reboot.c
>> +++ b/arch/x86/kernel/reboot.c
>> @@ -747,10 +747,10 @@ static void native_machine_halt(void)
>>
>> static void native_machine_power_off(void)
>> {
>> - if (pm_power_off) {
>> + if (kernel_can_power_off()) {
>> if (!reboot_force)
>> machine_shutdown();
>> - pm_power_off();
>> + do_kernel_power_off();
>> }
>
> Judging from an old commit from 2006 [1], this can be rewritten as:
>
> if (!reboot_force && kernel_can_power_off())
> machine_shutdown();
> do_kernel_power_off();
>
> And maybe later reworked so it doesn't need kernel_can_power_off().
>
> [1] http://lkml.iu.edu/hypermail//linux/kernel/0511.3/0681.html
It could be rewritten like you're suggesting, but I'd prefer to keep the
old variant, for clarity.
^ permalink raw reply
* Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API
From: Michał Mirosław @ 2021-11-28 21:17 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <9213569e-0f40-0df1-4710-8dab564e12d6@gmail.com>
On Mon, Nov 29, 2021 at 12:04:01AM +0300, Dmitry Osipenko wrote:
> 28.11.2021 03:43, Michał Mirosław пишет:
> > On Fri, Nov 26, 2021 at 09:00:44PM +0300, Dmitry Osipenko wrote:
> >> SoC platforms often have multiple ways of how to perform system's
> >> power-off and restart operations. Meanwhile today's kernel is limited to
> >> a single option. Add combined power-off+restart handler call chain API,
> >> which is inspired by the restart API. The new API provides both power-off
> >> and restart functionality.
> >>
> >> The old pm_power_off method will be kept around till all users are
> >> converted to the new API.
> >>
> >> Current restart API will be replaced by the new unified API since
> >> new API is its superset. The restart functionality of the sys-off handler
> >> API is built upon the existing restart-notifier APIs.
> >>
> >> In order to ease conversion to the new API, convenient helpers are added
> >> for the common use-cases. They will reduce amount of boilerplate code and
> >> remove global variables. These helpers preserve old behaviour for cases
> >> where only one power-off handler is expected, this is what all existing
> >> drivers want, and thus, they could be easily converted to the new API.
> >> Users of the new API should explicitly enable power-off chaining by
> >> setting corresponding flag of the power_handler structure.
> > [...]
> >
> > Hi,
> >
> > A general question: do we really need three distinct chains for this?
>
> Hello Michał,
>
> At minimum this makes code easier to follow.
>
> > Can't there be only one that chain of callbacks that get a stage
> > (RESTART_PREPARE, RESTART, POWER_OFF_PREPARE, POWER_OFF) and can ignore
> > them at will? Calling through POWER_OFF_PREPARE would also return
> > whether that POWER_OFF is possible (for kernel_can_power_off()).
>
> I'm having trouble with parsing this comment. Could you please try to
> rephrase it? I don't see how you could check whether power-off handler
> is available if you'll mix all handlers together.
If notify_call_chain() would be fixed to return NOTIFY_OK if any call
returned NOTIFY_OK, then this would be a clear way to gather the
answer if any of the handlers will attempt the final action (reboot or
power off).
>
> > I would also split this patch into preparation cleanups (like wrapping
> > pm_power_off call with a function) and adding the notifier-based
> > implementation.
>
> What's the benefit of this split up will be? Are you suggesting that it
> will ease reviewing of this patch or something else?
Mainly to ease review, as the wrapping will be a no-op, but the addition
of notifier chain changes semantics a bit.
Best Regards
Michał Mirosław
^ permalink raw reply
* Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API
From: Dmitry Osipenko @ 2021-11-28 21:53 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <YaPx0kY7poGpwCL9@qmqm.qmqm.pl>
29.11.2021 00:17, Michał Mirosław пишет:
>> I'm having trouble with parsing this comment. Could you please try to
>> rephrase it? I don't see how you could check whether power-off handler
>> is available if you'll mix all handlers together.
> If notify_call_chain() would be fixed to return NOTIFY_OK if any call
> returned NOTIFY_OK, then this would be a clear way to gather the
> answer if any of the handlers will attempt the final action (reboot or
> power off).
>
Could you please show a code snippet that implements your suggestion?
^ permalink raw reply
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-29 0:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #299711|0 |1
is obsolete| |
--- Comment #41 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299759
--> https://bugzilla.kernel.org/attachment.cgi?id=299759&action=edit
dmesg (5.15.5, OUTLINE KASAN, LOWMEM_SIZE=0x28000000, PowerMac G4 DP)
Ok, finally getting somewhere.. With CONFIG_LOWMEM_SIZE=0x28000000 I don't get
this "vmap allocation for size 33562624 failed" error and also OUTLINE KASAN
does not show the originally reported "BUG: Unable to handle kernel data access
at 0x00f0fd0d" for raid6_pq!
For INLINE KASAN I still get "vmap allocation for size 33562624 failed", even
with CONFIG_LOWMEM_SIZE=0x28000000 or CONFIG_LOWMEM_SIZE=0x20000000.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-29 0:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #299715|0 |1
is obsolete| |
--- Comment #43 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299763
--> https://bugzilla.kernel.org/attachment.cgi?id=299763&action=edit
kernel .config (5.15.5, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-29 0:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #42 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299761
--> https://bugzilla.kernel.org/attachment.cgi?id=299761&action=edit
dmesg (5.15.5, INLINE KASAN, LOWMEM_SIZE=0x20000000, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 0/9] lib/bitmap: optimize bitmap_weight() usage
From: Yury Norov @ 2021-11-28 23:36 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Juri Lelli, Andrew Lunn, Rafael J. Wysocki, Catalin Marinas,
Guo Ren, Christoph Lameter, Christoph Hellwig, Andi Kleen,
Vincent Guittot, Andy Gross, Geert Uytterhoeven, Mel Gorman,
Vineet Gupta, Petr Mladek, Arnaldo Carvalho de Melo, Jens Axboe,
Andy Lutomirski, Lee Jones, Greg Kroah-Hartman, Randy Dunlap,
linux-kernel, linux-perf-users, Sergey Senozhatsky,
Thomas Gleixner, linux-crypto, Tejun Heo, Andrew Morton,
Mark Rutland, Anup Patel, linux-ia64, David Airlie, Roy Pledge,
Dave Hansen, Solomon Peachy, Stephen Rothwell,
Krzysztof Kozlowski, Dennis Zhou, Matti Vaittinen, Sudeep Holla,
linux-arm-kernel, Stephen Boyd, Tariq Toukan, Dinh Nguyen,
Jonathan Cameron, Ulf Hansson, Alexander Shishkin,
Mike Marciniszyn, Rasmus Villemoes, Viresh Kumar,
Subbaraya Sundeep, Will Deacon, Sagi Grimberg, linux-csky,
bcm-kernel-feedback-list, Kalle Valo, linux-snps-arc, Kees Cook,
Arnd Bergmann, James E.J. Bottomley, Steven Rostedt, Mark Gross,
Borislav Petkov, Mauro Carvalho Chehab, Thomas Bogendoerfer,
Martin K. Petersen, David Laight, linux-alpha, Geetha sowjanya,
Ian Rogers, kvm, Peter Zijlstra, Amitkumar Karwar, linux-mm,
linux-riscv, Jiri Olsa, Ard Biesheuvel, Marc Zyngier,
Russell King, Ingo Molnar, Jakub Kicinski, Vivien Didelot,
Sunil Goutham, Paul E. McKenney, linux-s390, Alexey Klimov,
Heiko Carstens, Hans de Goede, Marcin Wojtas, Vlastimil Babka,
linuxppc-dev, linux-mips, Palmer Dabbelt, Daniel Vetter,
Jason Wessel, Saeed Mahameed, Andy Shevchenko
In-Reply-To: <1638096766.3elxdzb8ly.astroid@bobo.none>
On Sun, Nov 28, 2021 at 09:08:41PM +1000, Nicholas Piggin wrote:
> Excerpts from Yury Norov's message of November 28, 2021 1:56 pm:
> > In many cases people use bitmap_weight()-based functions like this:
> >
> > if (num_present_cpus() > 1)
> > do_something();
> >
> > This may take considerable amount of time on many-cpus machines because
> > num_present_cpus() will traverse every word of underlying cpumask
> > unconditionally.
> >
> > We can significantly improve on it for many real cases if stop traversing
> > the mask as soon as we count present cpus to any number greater than 1:
> >
> > if (num_present_cpus_gt(1))
> > do_something();
> >
> > To implement this idea, the series adds bitmap_weight_{eq,gt,le}
> > functions together with corresponding wrappers in cpumask and nodemask.
>
> There would be no change to callers if you maintain counters like what
> is done for num_online_cpus() today. Maybe some fixes to arch code that
> does not use set_cpu_possible() etc APIs required, but AFAIKS it would
> be better to fix such cases anyway.
Thanks, Nick. I'll try to do this.
^ permalink raw reply
* Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority
From: Michał Mirosław @ 2021-11-29 0:26 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <033ddf2a-6223-1a82-ec64-30f17c891f67@gmail.com>
On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
> 28.11.2021 03:28, Michał Mirosław пишет:
> > On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
> >> Add sanity check which ensures that there are no two restart handlers
> >> registered with the same priority. Normally it's a direct sign of a
> >> problem if two handlers use the same priority.
> >
> > The patch doesn't ensure the property that there are no duplicated-priority
> > entries on the chain.
>
> It's not the exact point of this patch.
>
> > I'd rather see a atomic_notifier_chain_register_unique() that returns
> > -EBUSY or something istead of adding an entry with duplicate priority.
> > That way it would need only one list traversal unless you want to
> > register the duplicate anyway (then you would call the older
> > atomic_notifier_chain_register() after reporting the error).
>
> The point of this patch is to warn developers about the problem that
> needs to be fixed. We already have such troubling drivers in mainline.
>
> It's not critical to register different handlers with a duplicated
> priorities, but such cases really need to be corrected. We shouldn't
> break users' machines during transition to the new API, meanwhile
> developers should take action of fixing theirs drivers.
>
> > (Or you could return > 0 when a duplicate is registered in
> > atomic_notifier_chain_register() if the callers are prepared
> > for that. I don't really like this way, though.)
>
> I had a similar thought at some point before and decided that I'm not in
> favor of this approach. It's nicer to have a dedicated function that
> verifies the uniqueness, IMO.
I don't like the part that it traverses the list second time to check
the uniqueness. But actually you could avoid that if
notifier_chain_register() would always add equal-priority entries in
reverse order:
static int notifier_chain_register(struct notifier_block **nl,
struct notifier_block *n)
{
while ((*nl) != NULL) {
if (unlikely((*nl) == n)) {
WARN(1, "double register detected");
return 0;
}
- if (n->priority > (*nl)->priority)
+ if (n->priority >= (*nl)->priority)
break;
nl = &((*nl)->next);
}
n->next = *nl;
rcu_assign_pointer(*nl, n);
return 0;
}
Then the check for uniqueness after adding would be:
WARN(nb->next && nb->priority == nb->next->priority);
Best Regards
Michał Mirosław
^ permalink raw reply
* Re: [PATCH v4 08/25] kernel: Add combined power-off+restart handler call chain API
From: Michał Mirosław @ 2021-11-29 0:36 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Ulf Hansson, Rich Felker, linux-ia64, Santosh Shilimkar,
Rafael J. Wysocki, Boris Ostrovsky, Linus Walleij, Dave Hansen,
Liam Girdwood, James E.J. Bottomley, Thierry Reding,
Paul Mackerras, Pavel Machek, H. Peter Anvin, linux-riscv,
Vincent Chen, Will Deacon, Greg Ungerer, Stefano Stabellini,
alankao, Yoshinori Sato, Krzysztof Kozlowski, linux-sh,
Helge Deller, x86, Russell King, linux-csky, Jonathan Hunter,
linux-acpi, Ingo Molnar, Geert Uytterhoeven, Catalin Marinas,
xen-devel, linux-mips, Guenter Roeck, Len Brown, Albert Ou,
Lee Jones, linux-m68k, Mark Brown, Borislav Petkov, Greentime Hu,
Paul Walmsley, linux-tegra, Thomas Gleixner, Andy Shevchenko,
linux-arm-kernel, Juergen Gross, Thomas Bogendoerfer,
Daniel Lezcano, linux-parisc, linux-pm, Sebastian Reichel,
linux-kernel, K . C . Kuen-Chern Lin, Palmer Dabbelt,
Philipp Zabel, Guo Ren, Andrew Morton, linuxppc-dev,
Joshua Thompson
In-Reply-To: <1fa2d9d5-f5f6-77f5-adf6-827921acce49@gmail.com>
On Mon, Nov 29, 2021 at 12:53:51AM +0300, Dmitry Osipenko wrote:
> 29.11.2021 00:17, Michał Mirosław пишет:
> >> I'm having trouble with parsing this comment. Could you please try to
> >> rephrase it? I don't see how you could check whether power-off handler
> >> is available if you'll mix all handlers together.
> > If notify_call_chain() would be fixed to return NOTIFY_OK if any call
> > returned NOTIFY_OK, then this would be a clear way to gather the
> > answer if any of the handlers will attempt the final action (reboot or
> > power off).
> Could you please show a code snippet that implements your suggestion?
A rough idea is this:
static int notifier_call_chain(struct notifier_block **nl,
unsigned long val, void *v,
int nr_to_call, int *nr_calls)
{
- int ret = NOTIFY_DONE;
+ int ret, result = NOTIFY_DONE;
struct notifier_block *nb, *next_nb;
nb = rcu_dereference_raw(*nl);
while (nb && nr_to_call) {
...
ret = nb->notifier_call(nb, val, v);
+
+ /* Assuming NOTIFY_STOP-carrying return is always greater than non-stopping one. */
+ if (result < ret)
+ result = ret;
...
}
- return ret;
+ return result;
}
Then:
bool prepare_reboot()
{
int ret = xx_notifier_call_chain(&shutdown_notifier, PREPARE_REBOOT, ...);
return ret == NOTIFY_OK;
}
And the return value would signify whether the reboot will be attempted
when calling the chain for the REBOOT action. (Analogously for powering off.)
Best Regards
Michał Mirosław
^ permalink raw reply
* Re: [PATCH RFC 0/4] mm: percpu: Cleanup percpu first chunk funciton
From: Kefeng Wang @ 2021-11-29 2:51 UTC (permalink / raw)
To: dennis, akpm, linux-kernel, linux-mm
Cc: linux-ia64, dave.hansen, paulus, hpa, sparclinux, cl, will,
linux-riscv, x86, mingo, catalin.marinas, aou, bp, paul.walmsley,
tglx, linux-arm-kernel, tsbogend, gregkh, linux-mips, palmer, tj,
linuxppc-dev, davem
In-Reply-To: <20211121093557.139034-1-wangkefeng.wang@huawei.com>
Hi Dennis and all maintainers, any comments about the changes, many thanks.
On 2021/11/21 17:35, Kefeng Wang wrote:
> When support page mapping percpu first chunk allocator on arm64, we
> found there are lots of duplicated codes in percpu embed/page first
> chunk allocator. This patchset is aimed to cleanup them and should
> no funciton change, only test on arm64.
>
> Kefeng Wang (4):
> mm: percpu: Generalize percpu related config
> mm: percpu: Add pcpu_fc_cpu_to_node_fn_t typedef
> mm: percpu: Add generic pcpu_fc_alloc/free funciton
> mm: percpu: Add generic pcpu_populate_pte() function
>
> arch/arm64/Kconfig | 20 +----
> arch/ia64/Kconfig | 9 +--
> arch/mips/Kconfig | 10 +--
> arch/mips/mm/init.c | 14 +---
> arch/powerpc/Kconfig | 17 +---
> arch/powerpc/kernel/setup_64.c | 92 +--------------------
> arch/riscv/Kconfig | 10 +--
> arch/sparc/Kconfig | 12 +--
> arch/sparc/kernel/smp_64.c | 105 +-----------------------
> arch/x86/Kconfig | 17 +---
> arch/x86/kernel/setup_percpu.c | 66 ++-------------
> drivers/base/arch_numa.c | 68 +---------------
> include/linux/percpu.h | 13 +--
> mm/Kconfig | 12 +++
> mm/percpu.c | 143 +++++++++++++++++++++++++--------
> 15 files changed, 165 insertions(+), 443 deletions(-)
>
^ permalink raw reply
* Re: [PATCH RFC 0/4] mm: percpu: Cleanup percpu first chunk funciton
From: Dennis Zhou @ 2021-11-29 2:54 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <4fecd1ac-6c0a-f0fa-1ffb-18f3f266809d@huawei.com>
On Mon, Nov 29, 2021 at 10:51:18AM +0800, Kefeng Wang wrote:
> Hi Dennis and all maintainers, any comments about the changes, many thanks.
>
> On 2021/11/21 17:35, Kefeng Wang wrote:
> > When support page mapping percpu first chunk allocator on arm64, we
> > found there are lots of duplicated codes in percpu embed/page first
> > chunk allocator. This patchset is aimed to cleanup them and should
> > no funciton change, only test on arm64.
> >
> > Kefeng Wang (4):
> > mm: percpu: Generalize percpu related config
> > mm: percpu: Add pcpu_fc_cpu_to_node_fn_t typedef
> > mm: percpu: Add generic pcpu_fc_alloc/free funciton
> > mm: percpu: Add generic pcpu_populate_pte() function
> >
> > arch/arm64/Kconfig | 20 +----
> > arch/ia64/Kconfig | 9 +--
> > arch/mips/Kconfig | 10 +--
> > arch/mips/mm/init.c | 14 +---
> > arch/powerpc/Kconfig | 17 +---
> > arch/powerpc/kernel/setup_64.c | 92 +--------------------
> > arch/riscv/Kconfig | 10 +--
> > arch/sparc/Kconfig | 12 +--
> > arch/sparc/kernel/smp_64.c | 105 +-----------------------
> > arch/x86/Kconfig | 17 +---
> > arch/x86/kernel/setup_percpu.c | 66 ++-------------
> > drivers/base/arch_numa.c | 68 +---------------
> > include/linux/percpu.h | 13 +--
> > mm/Kconfig | 12 +++
> > mm/percpu.c | 143 +++++++++++++++++++++++++--------
> > 15 files changed, 165 insertions(+), 443 deletions(-)
> >
Hi Kefang,
I apologize for the delay. It's a holiday week in the US + I had some
personal things come up at the beginning of last week. I'll have it
reviewed by tomorrow.
Thanks,
Dennis
^ permalink raw reply
* Re: [PATCH RFC 0/4] mm: percpu: Cleanup percpu first chunk funciton
From: Kefeng Wang @ 2021-11-29 3:06 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaRA6o0pHU6/206a@fedora>
On 2021/11/29 10:54, Dennis Zhou wrote:
> On Mon, Nov 29, 2021 at 10:51:18AM +0800, Kefeng Wang wrote:
>> Hi Dennis and all maintainers, any comments about the changes, many thanks.
>>
>> On 2021/11/21 17:35, Kefeng Wang wrote:
>>> When support page mapping percpu first chunk allocator on arm64, we
>>> found there are lots of duplicated codes in percpu embed/page first
>>> chunk allocator. This patchset is aimed to cleanup them and should
>>> no funciton change, only test on arm64.
>>>
>>> Kefeng Wang (4):
>>> mm: percpu: Generalize percpu related config
>>> mm: percpu: Add pcpu_fc_cpu_to_node_fn_t typedef
>>> mm: percpu: Add generic pcpu_fc_alloc/free funciton
>>> mm: percpu: Add generic pcpu_populate_pte() function
>>>
>>> arch/arm64/Kconfig | 20 +----
>>> arch/ia64/Kconfig | 9 +--
>>> arch/mips/Kconfig | 10 +--
>>> arch/mips/mm/init.c | 14 +---
>>> arch/powerpc/Kconfig | 17 +---
>>> arch/powerpc/kernel/setup_64.c | 92 +--------------------
>>> arch/riscv/Kconfig | 10 +--
>>> arch/sparc/Kconfig | 12 +--
>>> arch/sparc/kernel/smp_64.c | 105 +-----------------------
>>> arch/x86/Kconfig | 17 +---
>>> arch/x86/kernel/setup_percpu.c | 66 ++-------------
>>> drivers/base/arch_numa.c | 68 +---------------
>>> include/linux/percpu.h | 13 +--
>>> mm/Kconfig | 12 +++
>>> mm/percpu.c | 143 +++++++++++++++++++++++++--------
>>> 15 files changed, 165 insertions(+), 443 deletions(-)
>>>
> Hi Kefang,
>
> I apologize for the delay. It's a holiday week in the US + I had some
> personal things come up at the beginning of last week. I'll have it
> reviewed by tomorrow.
It's great to hear about your reply, thanks.
>
> Thanks,
> Dennis
> .
^ permalink raw reply
* [PATCH v5 01/17] powerpc: Remove unused FW_FEATURE_NATIVE references
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
FW_FEATURE_NATIVE_ALWAYS and FW_FEATURE_NATIVE_POSSIBLE are always
zero and never do anything. Remove them.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/firmware.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
index 97a3bd9ffeb9..9b702d2b80fb 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -80,8 +80,6 @@ enum {
FW_FEATURE_POWERNV_ALWAYS = 0,
FW_FEATURE_PS3_POSSIBLE = FW_FEATURE_LPAR | FW_FEATURE_PS3_LV1,
FW_FEATURE_PS3_ALWAYS = FW_FEATURE_LPAR | FW_FEATURE_PS3_LV1,
- FW_FEATURE_NATIVE_POSSIBLE = 0,
- FW_FEATURE_NATIVE_ALWAYS = 0,
FW_FEATURE_POSSIBLE =
#ifdef CONFIG_PPC_PSERIES
FW_FEATURE_PSERIES_POSSIBLE |
@@ -91,9 +89,6 @@ enum {
#endif
#ifdef CONFIG_PPC_PS3
FW_FEATURE_PS3_POSSIBLE |
-#endif
-#ifdef CONFIG_PPC_NATIVE
- FW_FEATURE_NATIVE_ALWAYS |
#endif
0,
FW_FEATURE_ALWAYS =
@@ -105,9 +100,6 @@ enum {
#endif
#ifdef CONFIG_PPC_PS3
FW_FEATURE_PS3_ALWAYS &
-#endif
-#ifdef CONFIG_PPC_NATIVE
- FW_FEATURE_NATIVE_ALWAYS &
#endif
FW_FEATURE_POSSIBLE,
--
2.23.0
^ permalink raw reply related
* [PATCH v5 00/17] powerpc: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Now that there's a platform that can make good use of it, here's
a series that can prevent the hash MMU code being built for 64s
platforms that don't need it.
Since v4:
- Fix 32s allnoconfig compile found by kernel test robot.
- Fix 64s platforms like cell that require hash but allow POWER9 CPU
and !HASH to be selected found by Christophe.
Since v3:
- Merged microwatt patches into 1.
- Fix some changelogs, titles, comments.
- Keep MMU_FTR_HPTE_TABLE in the features when booting radix if hash
support is is configured because it will be needed for KVM radix host
hash guest (when we extend this option to KVM).
- Accounted for hopefully all review comments (thanks Christophe)
Since v2:
- Split MMU_FTR_HPTE_TABLE clearing for radix boot into its own patch.
- Remove memremap_compat_align from other sub archs entirely.
- Flip patch order of the 2 main patches to put Kconfig change first.
- Fixed Book3S/32 xmon segment dumping bug.
- Removed a few more ifdefs, changed numbers to use SZ_ definitions,
etc.
- Fixed microwatt defconfig so it should actually disable hash MMU now.
Since v1:
- Split out most of the Kconfig change from the conditional compilation
changes.
- Split out several more changes into preparatory patches.
- Reduced some ifdefs.
- Caught a few missing hash bits: pgtable dump, lkdtm,
memremap_compat_align.
Since RFC:
- Split out large code movement from other changes.
- Used mmu ftr test constant folding rather than adding new constant
true/false for radix_enabled().
- Restore tlbie trace point that had to be commented out in the
previous.
- Avoid minor (probably unreachable) behaviour change in machine check
handler when hash was not compiled.
- Fix microwatt updates so !HASH is not enforced.
- Rebase, build fixes.
Thanks,
Nick
Nicholas Piggin (17):
powerpc: Remove unused FW_FEATURE_NATIVE references
powerpc: Rename PPC_NATIVE to PPC_HASH_MMU_NATIVE
powerpc/pseries: Stop selecting PPC_HASH_MMU_NATIVE
powerpc/64s: Move and rename do_bad_slb_fault as it is not hash
specific
powerpc/pseries: move process table registration away from
hash-specific code
powerpc/pseries: lparcfg don't include slb_size line in radix mode
powerpc/64s: move THP trace point creation out of hash specific file
powerpc/64s: Make flush_and_reload_slb a no-op when radix is enabled
powerpc/64s: move page size definitions from hash specific file
powerpc/64s: Rename hash_hugetlbpage.c to hugetlbpage.c
powerpc/64: pcpu setup avoid reading mmu_linear_psize on 64e or radix
powerpc: make memremap_compat_align 64s-only
powerpc/64e: remove mmu_linear_psize
powerpc/64s: Fix radix MMU when MMU_FTR_HPTE_TABLE is clear
powerpc/64s: Make hash MMU support configurable
powerpc/64s: Move hash MMU support code under CONFIG_PPC_64S_HASH_MMU
powerpc/microwatt: add POWER9_CPU, clear PPC_64S_HASH_MMU
arch/powerpc/Kconfig | 5 +-
arch/powerpc/configs/microwatt_defconfig | 3 +-
arch/powerpc/include/asm/book3s/64/mmu.h | 21 +++-
.../include/asm/book3s/64/tlbflush-hash.h | 6 +
arch/powerpc/include/asm/book3s/64/tlbflush.h | 4 -
arch/powerpc/include/asm/book3s/pgtable.h | 4 +
arch/powerpc/include/asm/firmware.h | 8 --
arch/powerpc/include/asm/interrupt.h | 2 +-
arch/powerpc/include/asm/mmu.h | 16 ++-
arch/powerpc/include/asm/mmu_context.h | 2 +
arch/powerpc/include/asm/nohash/mmu-book3e.h | 1 -
arch/powerpc/include/asm/paca.h | 8 ++
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/dt_cpu_ftrs.c | 14 ++-
arch/powerpc/kernel/entry_64.S | 4 +-
arch/powerpc/kernel/exceptions-64s.S | 20 +++-
arch/powerpc/kernel/mce.c | 2 +-
arch/powerpc/kernel/mce_power.c | 16 ++-
arch/powerpc/kernel/paca.c | 18 ++-
arch/powerpc/kernel/process.c | 13 +-
arch/powerpc/kernel/prom.c | 2 +
arch/powerpc/kernel/setup_64.c | 26 +++-
arch/powerpc/kexec/core_64.c | 4 +-
arch/powerpc/kexec/ranges.c | 4 +
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/mm/book3s64/Makefile | 19 +--
arch/powerpc/mm/book3s64/hash_native.c | 104 ----------------
arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
arch/powerpc/mm/book3s64/hash_utils.c | 111 +++++++++++++++++-
.../{hash_hugetlbpage.c => hugetlbpage.c} | 2 +
arch/powerpc/mm/book3s64/mmu_context.c | 32 ++++-
arch/powerpc/mm/book3s64/pgtable.c | 27 +++++
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 +
arch/powerpc/mm/book3s64/slb.c | 16 ---
arch/powerpc/mm/book3s64/trace.c | 8 ++
arch/powerpc/mm/copro_fault.c | 2 +
arch/powerpc/mm/fault.c | 24 ++++
arch/powerpc/mm/init_64.c | 13 +-
arch/powerpc/mm/ioremap.c | 20 ----
arch/powerpc/mm/nohash/tlb.c | 9 --
arch/powerpc/mm/pgtable.c | 9 +-
arch/powerpc/mm/ptdump/Makefile | 2 +-
arch/powerpc/platforms/52xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 4 +-
arch/powerpc/platforms/Kconfig.cputype | 23 +++-
arch/powerpc/platforms/cell/Kconfig | 3 +-
arch/powerpc/platforms/chrp/Kconfig | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 2 +-
arch/powerpc/platforms/maple/Kconfig | 3 +-
arch/powerpc/platforms/microwatt/Kconfig | 1 -
arch/powerpc/platforms/pasemi/Kconfig | 3 +-
arch/powerpc/platforms/powermac/Kconfig | 3 +-
arch/powerpc/platforms/powernv/Kconfig | 2 +-
arch/powerpc/platforms/powernv/idle.c | 2 +
arch/powerpc/platforms/powernv/setup.c | 2 +
arch/powerpc/platforms/pseries/Kconfig | 1 -
arch/powerpc/platforms/pseries/lpar.c | 67 ++++++-----
arch/powerpc/platforms/pseries/lparcfg.c | 5 +-
arch/powerpc/platforms/pseries/mobility.c | 6 +
arch/powerpc/platforms/pseries/ras.c | 2 +
arch/powerpc/platforms/pseries/reconfig.c | 2 +
arch/powerpc/platforms/pseries/setup.c | 6 +-
arch/powerpc/xmon/xmon.c | 8 +-
drivers/misc/lkdtm/Makefile | 2 +-
drivers/misc/lkdtm/core.c | 2 +-
65 files changed, 470 insertions(+), 292 deletions(-)
rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (99%)
create mode 100644 arch/powerpc/mm/book3s64/trace.c
--
2.23.0
^ permalink raw reply
* [PATCH v5 02/17] powerpc: Rename PPC_NATIVE to PPC_HASH_MMU_NATIVE
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
PPC_NATIVE now only controls the native HPT code, so rename it to be
more descriptive. Restrict it to Book3S only.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/book3s64/Makefile | 2 +-
arch/powerpc/mm/book3s64/hash_utils.c | 2 +-
arch/powerpc/platforms/52xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 4 ++--
arch/powerpc/platforms/cell/Kconfig | 2 +-
arch/powerpc/platforms/chrp/Kconfig | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 2 +-
arch/powerpc/platforms/maple/Kconfig | 2 +-
arch/powerpc/platforms/microwatt/Kconfig | 2 +-
arch/powerpc/platforms/pasemi/Kconfig | 2 +-
arch/powerpc/platforms/powermac/Kconfig | 2 +-
arch/powerpc/platforms/powernv/Kconfig | 2 +-
arch/powerpc/platforms/pseries/Kconfig | 2 +-
13 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/Makefile b/arch/powerpc/mm/book3s64/Makefile
index 1b56d3af47d4..319f4b7f3357 100644
--- a/arch/powerpc/mm/book3s64/Makefile
+++ b/arch/powerpc/mm/book3s64/Makefile
@@ -6,7 +6,7 @@ CFLAGS_REMOVE_slb.o = $(CC_FLAGS_FTRACE)
obj-y += hash_pgtable.o hash_utils.o slb.o \
mmu_context.o pgtable.o hash_tlb.o
-obj-$(CONFIG_PPC_NATIVE) += hash_native.o
+obj-$(CONFIG_PPC_HASH_MMU_NATIVE) += hash_native.o
obj-$(CONFIG_PPC_RADIX_MMU) += radix_pgtable.o radix_tlb.o
obj-$(CONFIG_PPC_4K_PAGES) += hash_4k.o
obj-$(CONFIG_PPC_64K_PAGES) += hash_64k.o
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index cfd45245d009..92680da5229a 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1091,7 +1091,7 @@ void __init hash__early_init_mmu(void)
ps3_early_mm_init();
else if (firmware_has_feature(FW_FEATURE_LPAR))
hpte_init_pseries();
- else if (IS_ENABLED(CONFIG_PPC_NATIVE))
+ else if (IS_ENABLED(CONFIG_PPC_HASH_MMU_NATIVE))
hpte_init_native();
if (!mmu_hash_ops.hpte_insert)
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 99d60acc20c8..b72ed2950ca8 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -34,7 +34,7 @@ config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MPC52xx
select PPC_RTAS
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
config PPC_LITE5200
bool "Freescale Lite5200 Eval Board"
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e02d29a9d12f..d41dad227de8 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -40,9 +40,9 @@ config EPAPR_PARAVIRT
In case of doubt, say Y
-config PPC_NATIVE
+config PPC_HASH_MMU_NATIVE
bool
- depends on PPC_BOOK3S_32 || PPC64
+ depends on PPC_BOOK3S
help
Support for running natively on the hardware, i.e. without
a hypervisor. This option is not user-selectable but should
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index cb70c5f25bc6..db4465c51b56 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -8,7 +8,7 @@ config PPC_CELL_COMMON
select PPC_DCR_MMIO
select PPC_INDIRECT_PIO
select PPC_INDIRECT_MMIO
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_RTAS
select IRQ_EDGE_EOI_HANDLER
diff --git a/arch/powerpc/platforms/chrp/Kconfig b/arch/powerpc/platforms/chrp/Kconfig
index 9b5c5505718a..ff30ed579a39 100644
--- a/arch/powerpc/platforms/chrp/Kconfig
+++ b/arch/powerpc/platforms/chrp/Kconfig
@@ -11,6 +11,6 @@ config PPC_CHRP
select RTAS_ERROR_LOGGING
select PPC_MPC106
select PPC_UDBG_16550
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select FORCE_PCI
default y
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 4c6d703a4284..c54786f8461e 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -55,7 +55,7 @@ config MVME5100
select FORCE_PCI
select PPC_INDIRECT_PCI
select PPC_I8259
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_UDBG_16550
help
This option enables support for the Motorola (now Emerson) MVME5100
diff --git a/arch/powerpc/platforms/maple/Kconfig b/arch/powerpc/platforms/maple/Kconfig
index 86ae210bee9a..7fd84311ade5 100644
--- a/arch/powerpc/platforms/maple/Kconfig
+++ b/arch/powerpc/platforms/maple/Kconfig
@@ -9,7 +9,7 @@ config PPC_MAPLE
select GENERIC_TBSYNC
select PPC_UDBG_16550
select PPC_970_NAP
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_RTAS
select MMIO_NVRAM
select ATA_NONSTANDARD if ATA
diff --git a/arch/powerpc/platforms/microwatt/Kconfig b/arch/powerpc/platforms/microwatt/Kconfig
index 8f6a81978461..62b51e37fc05 100644
--- a/arch/powerpc/platforms/microwatt/Kconfig
+++ b/arch/powerpc/platforms/microwatt/Kconfig
@@ -5,7 +5,7 @@ config PPC_MICROWATT
select PPC_XICS
select PPC_ICS_NATIVE
select PPC_ICP_NATIVE
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_UDBG_16550
select ARCH_RANDOM
help
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index c52731a7773f..bc7137353a7f 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,7 +5,7 @@ config PPC_PASEMI
select MPIC
select FORCE_PCI
select PPC_UDBG_16550
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig
index b97bf12801eb..2b56df145b82 100644
--- a/arch/powerpc/platforms/powermac/Kconfig
+++ b/arch/powerpc/platforms/powermac/Kconfig
@@ -6,7 +6,7 @@ config PPC_PMAC
select FORCE_PCI
select PPC_INDIRECT_PCI if PPC32
select PPC_MPC106 if PPC32
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select ZONE_DMA if PPC32
default y
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
index 043eefbbdd28..cd754e116184 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -2,7 +2,7 @@
config PPC_POWERNV
depends on PPC64 && PPC_BOOK3S
bool "IBM PowerNV (Non-Virtualized) platform support"
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_XICS
select PPC_ICP_NATIVE
select PPC_XIVE_NATIVE
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 9bd542164128..30618750bd98 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -17,7 +17,7 @@ config PPC_PSERIES
select PPC_RTAS_DAEMON
select RTAS_ERROR_LOGGING
select PPC_UDBG_16550
- select PPC_NATIVE
+ select PPC_HASH_MMU_NATIVE
select PPC_DOORBELL
select HOTPLUG_CPU
select ARCH_RANDOM
--
2.23.0
^ permalink raw reply related
* [PATCH v5 03/17] powerpc/pseries: Stop selecting PPC_HASH_MMU_NATIVE
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
The pseries platform does not use the native hash code but the PAPR
virtualised hash interfaces, so remove PPC_HASH_MMU_NATIVE.
This requires moving tlbiel code from hash_native.c to hash_utils.c.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/book3s/64/tlbflush.h | 4 -
arch/powerpc/mm/book3s64/hash_native.c | 104 ------------------
arch/powerpc/mm/book3s64/hash_utils.c | 104 ++++++++++++++++++
arch/powerpc/platforms/pseries/Kconfig | 1 -
4 files changed, 104 insertions(+), 109 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 215973b4cb26..d2e80f178b6d 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -14,7 +14,6 @@ enum {
TLB_INVAL_SCOPE_LPID = 1, /* invalidate TLBs for current LPID */
};
-#ifdef CONFIG_PPC_NATIVE
static inline void tlbiel_all(void)
{
/*
@@ -30,9 +29,6 @@ static inline void tlbiel_all(void)
else
hash__tlbiel_all(TLB_INVAL_SCOPE_GLOBAL);
}
-#else
-static inline void tlbiel_all(void) { BUG(); }
-#endif
static inline void tlbiel_all_lpid(bool radix)
{
diff --git a/arch/powerpc/mm/book3s64/hash_native.c b/arch/powerpc/mm/book3s64/hash_native.c
index d8279bfe68ea..d2a320828c0b 100644
--- a/arch/powerpc/mm/book3s64/hash_native.c
+++ b/arch/powerpc/mm/book3s64/hash_native.c
@@ -43,110 +43,6 @@
static DEFINE_RAW_SPINLOCK(native_tlbie_lock);
-static inline void tlbiel_hash_set_isa206(unsigned int set, unsigned int is)
-{
- unsigned long rb;
-
- rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
-
- asm volatile("tlbiel %0" : : "r" (rb));
-}
-
-/*
- * tlbiel instruction for hash, set invalidation
- * i.e., r=1 and is=01 or is=10 or is=11
- */
-static __always_inline void tlbiel_hash_set_isa300(unsigned int set, unsigned int is,
- unsigned int pid,
- unsigned int ric, unsigned int prs)
-{
- unsigned long rb;
- unsigned long rs;
- unsigned int r = 0; /* hash format */
-
- rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
- rs = ((unsigned long)pid << PPC_BITLSHIFT(31));
-
- asm volatile(PPC_TLBIEL(%0, %1, %2, %3, %4)
- : : "r"(rb), "r"(rs), "i"(ric), "i"(prs), "i"(r)
- : "memory");
-}
-
-
-static void tlbiel_all_isa206(unsigned int num_sets, unsigned int is)
-{
- unsigned int set;
-
- asm volatile("ptesync": : :"memory");
-
- for (set = 0; set < num_sets; set++)
- tlbiel_hash_set_isa206(set, is);
-
- ppc_after_tlbiel_barrier();
-}
-
-static void tlbiel_all_isa300(unsigned int num_sets, unsigned int is)
-{
- unsigned int set;
-
- asm volatile("ptesync": : :"memory");
-
- /*
- * Flush the partition table cache if this is HV mode.
- */
- if (early_cpu_has_feature(CPU_FTR_HVMODE))
- tlbiel_hash_set_isa300(0, is, 0, 2, 0);
-
- /*
- * Now invalidate the process table cache. UPRT=0 HPT modes (what
- * current hardware implements) do not use the process table, but
- * add the flushes anyway.
- *
- * From ISA v3.0B p. 1078:
- * The following forms are invalid.
- * * PRS=1, R=0, and RIC!=2 (The only process-scoped
- * HPT caching is of the Process Table.)
- */
- tlbiel_hash_set_isa300(0, is, 0, 2, 1);
-
- /*
- * Then flush the sets of the TLB proper. Hash mode uses
- * partition scoped TLB translations, which may be flushed
- * in !HV mode.
- */
- for (set = 0; set < num_sets; set++)
- tlbiel_hash_set_isa300(set, is, 0, 0, 0);
-
- ppc_after_tlbiel_barrier();
-
- asm volatile(PPC_ISA_3_0_INVALIDATE_ERAT "; isync" : : :"memory");
-}
-
-void hash__tlbiel_all(unsigned int action)
-{
- unsigned int is;
-
- switch (action) {
- case TLB_INVAL_SCOPE_GLOBAL:
- is = 3;
- break;
- case TLB_INVAL_SCOPE_LPID:
- is = 2;
- break;
- default:
- BUG();
- }
-
- if (early_cpu_has_feature(CPU_FTR_ARCH_300))
- tlbiel_all_isa300(POWER9_TLB_SETS_HASH, is);
- else if (early_cpu_has_feature(CPU_FTR_ARCH_207S))
- tlbiel_all_isa206(POWER8_TLB_SETS, is);
- else if (early_cpu_has_feature(CPU_FTR_ARCH_206))
- tlbiel_all_isa206(POWER7_TLB_SETS, is);
- else
- WARN(1, "%s called on pre-POWER7 CPU\n", __func__);
-}
-
static inline unsigned long ___tlbie(unsigned long vpn, int psize,
int apsize, int ssize)
{
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index 92680da5229a..97a36fa3940e 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -175,6 +175,110 @@ static struct mmu_psize_def mmu_psize_defaults_gp[] = {
},
};
+static inline void tlbiel_hash_set_isa206(unsigned int set, unsigned int is)
+{
+ unsigned long rb;
+
+ rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
+
+ asm volatile("tlbiel %0" : : "r" (rb));
+}
+
+/*
+ * tlbiel instruction for hash, set invalidation
+ * i.e., r=1 and is=01 or is=10 or is=11
+ */
+static __always_inline void tlbiel_hash_set_isa300(unsigned int set, unsigned int is,
+ unsigned int pid,
+ unsigned int ric, unsigned int prs)
+{
+ unsigned long rb;
+ unsigned long rs;
+ unsigned int r = 0; /* hash format */
+
+ rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
+ rs = ((unsigned long)pid << PPC_BITLSHIFT(31));
+
+ asm volatile(PPC_TLBIEL(%0, %1, %2, %3, %4)
+ : : "r"(rb), "r"(rs), "i"(ric), "i"(prs), "i"(r)
+ : "memory");
+}
+
+
+static void tlbiel_all_isa206(unsigned int num_sets, unsigned int is)
+{
+ unsigned int set;
+
+ asm volatile("ptesync": : :"memory");
+
+ for (set = 0; set < num_sets; set++)
+ tlbiel_hash_set_isa206(set, is);
+
+ ppc_after_tlbiel_barrier();
+}
+
+static void tlbiel_all_isa300(unsigned int num_sets, unsigned int is)
+{
+ unsigned int set;
+
+ asm volatile("ptesync": : :"memory");
+
+ /*
+ * Flush the partition table cache if this is HV mode.
+ */
+ if (early_cpu_has_feature(CPU_FTR_HVMODE))
+ tlbiel_hash_set_isa300(0, is, 0, 2, 0);
+
+ /*
+ * Now invalidate the process table cache. UPRT=0 HPT modes (what
+ * current hardware implements) do not use the process table, but
+ * add the flushes anyway.
+ *
+ * From ISA v3.0B p. 1078:
+ * The following forms are invalid.
+ * * PRS=1, R=0, and RIC!=2 (The only process-scoped
+ * HPT caching is of the Process Table.)
+ */
+ tlbiel_hash_set_isa300(0, is, 0, 2, 1);
+
+ /*
+ * Then flush the sets of the TLB proper. Hash mode uses
+ * partition scoped TLB translations, which may be flushed
+ * in !HV mode.
+ */
+ for (set = 0; set < num_sets; set++)
+ tlbiel_hash_set_isa300(set, is, 0, 0, 0);
+
+ ppc_after_tlbiel_barrier();
+
+ asm volatile(PPC_ISA_3_0_INVALIDATE_ERAT "; isync" : : :"memory");
+}
+
+void hash__tlbiel_all(unsigned int action)
+{
+ unsigned int is;
+
+ switch (action) {
+ case TLB_INVAL_SCOPE_GLOBAL:
+ is = 3;
+ break;
+ case TLB_INVAL_SCOPE_LPID:
+ is = 2;
+ break;
+ default:
+ BUG();
+ }
+
+ if (early_cpu_has_feature(CPU_FTR_ARCH_300))
+ tlbiel_all_isa300(POWER9_TLB_SETS_HASH, is);
+ else if (early_cpu_has_feature(CPU_FTR_ARCH_207S))
+ tlbiel_all_isa206(POWER8_TLB_SETS, is);
+ else if (early_cpu_has_feature(CPU_FTR_ARCH_206))
+ tlbiel_all_isa206(POWER7_TLB_SETS, is);
+ else
+ WARN(1, "%s called on pre-POWER7 CPU\n", __func__);
+}
+
/*
* 'R' and 'C' update notes:
* - Under pHyp or KVM, the updatepp path will not set C, thus it *will*
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 30618750bd98..f7fd91d153a4 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -17,7 +17,6 @@ config PPC_PSERIES
select PPC_RTAS_DAEMON
select RTAS_ERROR_LOGGING
select PPC_UDBG_16550
- select PPC_HASH_MMU_NATIVE
select PPC_DOORBELL
select HOTPLUG_CPU
select ARCH_RANDOM
--
2.23.0
^ permalink raw reply related
* [PATCH v5 04/17] powerpc/64s: Move and rename do_bad_slb_fault as it is not hash specific
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
slb.c is hash-specific SLB management, but do_bad_slb_fault deals with
segment interrupts that occur with radix MMU as well.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 2 +-
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
arch/powerpc/mm/book3s64/slb.c | 16 ----------------
arch/powerpc/mm/fault.c | 24 ++++++++++++++++++++++++
4 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index a1d238255f07..3487aab12229 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -564,7 +564,7 @@ DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
/* slb.c */
DECLARE_INTERRUPT_HANDLER_RAW(do_slb_fault);
-DECLARE_INTERRUPT_HANDLER(do_bad_slb_fault);
+DECLARE_INTERRUPT_HANDLER(do_bad_segment_interrupt);
/* hash_utils.c */
DECLARE_INTERRUPT_HANDLER_RAW(do_hash_fault);
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index eaf1f72131a1..046c99e31d01 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1430,7 +1430,7 @@ MMU_FTR_SECTION_ELSE
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
std r3,RESULT(r1)
addi r3,r1,STACK_FRAME_OVERHEAD
- bl do_bad_slb_fault
+ bl do_bad_segment_interrupt
b interrupt_return_srr
@@ -1510,7 +1510,7 @@ MMU_FTR_SECTION_ELSE
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
std r3,RESULT(r1)
addi r3,r1,STACK_FRAME_OVERHEAD
- bl do_bad_slb_fault
+ bl do_bad_segment_interrupt
b interrupt_return_srr
diff --git a/arch/powerpc/mm/book3s64/slb.c b/arch/powerpc/mm/book3s64/slb.c
index f0037bcc47a0..31f4cef3adac 100644
--- a/arch/powerpc/mm/book3s64/slb.c
+++ b/arch/powerpc/mm/book3s64/slb.c
@@ -868,19 +868,3 @@ DEFINE_INTERRUPT_HANDLER_RAW(do_slb_fault)
return err;
}
}
-
-DEFINE_INTERRUPT_HANDLER(do_bad_slb_fault)
-{
- int err = regs->result;
-
- if (err == -EFAULT) {
- if (user_mode(regs))
- _exception(SIGSEGV, regs, SEGV_BNDERR, regs->dar);
- else
- bad_page_fault(regs, SIGSEGV);
- } else if (err == -EINVAL) {
- unrecoverable_exception(regs);
- } else {
- BUG();
- }
-}
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index a8d0ce85d39a..2d4a411c7c85 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -35,6 +35,7 @@
#include <linux/kfence.h>
#include <linux/pkeys.h>
+#include <asm/asm-prototypes.h>
#include <asm/firmware.h>
#include <asm/interrupt.h>
#include <asm/page.h>
@@ -620,4 +621,27 @@ DEFINE_INTERRUPT_HANDLER(do_bad_page_fault_segv)
{
bad_page_fault(regs, SIGSEGV);
}
+
+/*
+ * In radix, segment interrupts indicate the EA is not addressable by the
+ * page table geometry, so they are always sent here.
+ *
+ * In hash, this is called if do_slb_fault returns error. Typically it is
+ * because the EA was outside the region allowed by software.
+ */
+DEFINE_INTERRUPT_HANDLER(do_bad_segment_interrupt)
+{
+ int err = regs->result;
+
+ if (err == -EFAULT) {
+ if (user_mode(regs))
+ _exception(SIGSEGV, regs, SEGV_BNDERR, regs->dar);
+ else
+ bad_page_fault(regs, SIGSEGV);
+ } else if (err == -EINVAL) {
+ unrecoverable_exception(regs);
+ } else {
+ BUG();
+ }
+}
#endif
--
2.23.0
^ permalink raw reply related
* [PATCH v5 05/17] powerpc/pseries: move process table registration away from hash-specific code
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
This reduces ifdefs in a later change which makes hash support configurable.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/lpar.c | 56 +++++++++++++--------------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 3df6bdfea475..06d6a824c0dc 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -712,6 +712,34 @@ void vpa_init(int cpu)
#ifdef CONFIG_PPC_BOOK3S_64
+static int pseries_lpar_register_process_table(unsigned long base,
+ unsigned long page_size, unsigned long table_size)
+{
+ long rc;
+ unsigned long flags = 0;
+
+ if (table_size)
+ flags |= PROC_TABLE_NEW;
+ if (radix_enabled()) {
+ flags |= PROC_TABLE_RADIX;
+ if (mmu_has_feature(MMU_FTR_GTSE))
+ flags |= PROC_TABLE_GTSE;
+ } else
+ flags |= PROC_TABLE_HPT_SLB;
+ for (;;) {
+ rc = plpar_hcall_norets(H_REGISTER_PROC_TBL, flags, base,
+ page_size, table_size);
+ if (!H_IS_LONG_BUSY(rc))
+ break;
+ mdelay(get_longbusy_msecs(rc));
+ }
+ if (rc != H_SUCCESS) {
+ pr_err("Failed to register process table (rc=%ld)\n", rc);
+ BUG();
+ }
+ return rc;
+}
+
static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
unsigned long vpn, unsigned long pa,
unsigned long rflags, unsigned long vflags,
@@ -1680,34 +1708,6 @@ static int pseries_lpar_resize_hpt(unsigned long shift)
return 0;
}
-static int pseries_lpar_register_process_table(unsigned long base,
- unsigned long page_size, unsigned long table_size)
-{
- long rc;
- unsigned long flags = 0;
-
- if (table_size)
- flags |= PROC_TABLE_NEW;
- if (radix_enabled()) {
- flags |= PROC_TABLE_RADIX;
- if (mmu_has_feature(MMU_FTR_GTSE))
- flags |= PROC_TABLE_GTSE;
- } else
- flags |= PROC_TABLE_HPT_SLB;
- for (;;) {
- rc = plpar_hcall_norets(H_REGISTER_PROC_TBL, flags, base,
- page_size, table_size);
- if (!H_IS_LONG_BUSY(rc))
- break;
- mdelay(get_longbusy_msecs(rc));
- }
- if (rc != H_SUCCESS) {
- pr_err("Failed to register process table (rc=%ld)\n", rc);
- BUG();
- }
- return rc;
-}
-
void __init hpte_init_pseries(void)
{
mmu_hash_ops.hpte_invalidate = pSeries_lpar_hpte_invalidate;
--
2.23.0
^ permalink raw reply related
* [PATCH v5 06/17] powerpc/pseries: lparcfg don't include slb_size line in radix mode
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
This avoids a change in behaviour in the later patch making hash
support configurable. This is possibly a user interface change, so
the alternative would be a hard-coded slb_size=0 here.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/lparcfg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
index f71eac74ea92..3354c00914fa 100644
--- a/arch/powerpc/platforms/pseries/lparcfg.c
+++ b/arch/powerpc/platforms/pseries/lparcfg.c
@@ -532,7 +532,8 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
lppaca_shared_proc(get_lppaca()));
#ifdef CONFIG_PPC_BOOK3S_64
- seq_printf(m, "slb_size=%d\n", mmu_slb_size);
+ if (!radix_enabled())
+ seq_printf(m, "slb_size=%d\n", mmu_slb_size);
#endif
parse_em_data(m);
maxmem_data(m);
--
2.23.0
^ permalink raw reply related
* [PATCH v5 07/17] powerpc/64s: move THP trace point creation out of hash specific file
From: Nicholas Piggin @ 2021-11-29 3:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211129030803.1888161-1-npiggin@gmail.com>
In preparation for making hash MMU support configurable, move THP
trace point function definitions out of an otherwise hash-specific
file.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/book3s64/Makefile | 2 +-
arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
arch/powerpc/mm/book3s64/trace.c | 8 ++++++++
3 files changed, 9 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/mm/book3s64/trace.c
diff --git a/arch/powerpc/mm/book3s64/Makefile b/arch/powerpc/mm/book3s64/Makefile
index 319f4b7f3357..1579e18e098d 100644
--- a/arch/powerpc/mm/book3s64/Makefile
+++ b/arch/powerpc/mm/book3s64/Makefile
@@ -5,7 +5,7 @@ ccflags-y := $(NO_MINIMAL_TOC)
CFLAGS_REMOVE_slb.o = $(CC_FLAGS_FTRACE)
obj-y += hash_pgtable.o hash_utils.o slb.o \
- mmu_context.o pgtable.o hash_tlb.o
+ mmu_context.o pgtable.o hash_tlb.o trace.o
obj-$(CONFIG_PPC_HASH_MMU_NATIVE) += hash_native.o
obj-$(CONFIG_PPC_RADIX_MMU) += radix_pgtable.o radix_tlb.o
obj-$(CONFIG_PPC_4K_PAGES) += hash_4k.o
diff --git a/arch/powerpc/mm/book3s64/hash_pgtable.c b/arch/powerpc/mm/book3s64/hash_pgtable.c
index ad5eff097d31..7ce8914992e3 100644
--- a/arch/powerpc/mm/book3s64/hash_pgtable.c
+++ b/arch/powerpc/mm/book3s64/hash_pgtable.c
@@ -16,7 +16,6 @@
#include <mm/mmu_decl.h>
-#define CREATE_TRACE_POINTS
#include <trace/events/thp.h>
#if H_PGTABLE_RANGE > (USER_VSID_RANGE * (TASK_SIZE_USER64 / TASK_CONTEXT_SIZE))
diff --git a/arch/powerpc/mm/book3s64/trace.c b/arch/powerpc/mm/book3s64/trace.c
new file mode 100644
index 000000000000..b86e7b906257
--- /dev/null
+++ b/arch/powerpc/mm/book3s64/trace.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * This file is for defining trace points and trace related helpers.
+ */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define CREATE_TRACE_POINTS
+#include <trace/events/thp.h>
+#endif
--
2.23.0
^ permalink raw reply related
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