* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Miguel Ojeda @ 2021-05-04 8:38 UTC (permalink / raw)
To: Ben Dooks
Cc: Albert Ou, Arnd Bergmann, Linux Kbuild mailing list,
Greg Kroah-Hartman, Masahiro Yamada, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Miguel Ojeda, Will Deacon,
Palmer Dabbelt, Paul Walmsley, Catalin Marinas, Joe Perches,
Paul Mackerras, linux-riscv, linuxppc-dev, Linus Torvalds,
Linux ARM
In-Reply-To: <65cda2bb-1b02-6ebc-0ea2-c48927524aa0@codethink.co.uk>
On Tue, May 4, 2021 at 9:57 AM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>
> Some of us are a bit stuck as either customer refuses to upgrade
> their build infrastructure or has paid for some old but safety
> blessed version of gcc. These often lag years behind the recent
> gcc releases :(
In those scenarios, why do you need to build mainline? Aren't your
customers using longterm or frozen kernels? If they are paying for
certified GCC images, aren't they already paying for supported kernel
images from some vendor too?
I understand where you are coming from -- I have also dealt with
projects/machines running ancient, unsupported software/toolchains for
various reasons; but nobody expected upstream (and in particular the
mainline kernel source) to support them. In the cases I experienced,
those use cases require not touching anything at all, and when the
time came of doing so, everything would be updated at once,
re-certified/validated as needed and frozen again.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Ben Dooks @ 2021-05-04 7:56 UTC (permalink / raw)
To: Joe Perches, Miguel Ojeda, Masahiro Yamada
Cc: Albert Ou, Arnd Bergmann, Linux Kbuild mailing list,
Greg Kroah-Hartman, Jonathan Corbet, Linux Doc Mailing List,
linux-kernel, Linus Torvalds, Palmer Dabbelt, Paul Walmsley,
Catalin Marinas, Miguel Ojeda, Paul Mackerras, linux-riscv,
linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com>
On 02/05/2021 03:41, Joe Perches wrote:
> On Sat, 2021-05-01 at 17:52 +0200, Miguel Ojeda wrote:
>> On Sat, May 1, 2021 at 5:17 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>>>
>>> More cleanups will be possible as follow-up patches, but this one must
>>> be agreed and applied to the mainline first.
>>
>> +1 This will allow me to remove the __has_attribute hack in
>> include/linux/compiler_attributes.h.
>
> Why not raise the minimum gcc compiler version even higher?
>
> https://gcc.gnu.org/releases.html
Some of us are a bit stuck as either customer refuses to upgrade
their build infrastructure or has paid for some old but safety
blessed version of gcc. These often lag years behind the recent
gcc releases :(
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 8:58 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <daace050-6233-77ea-4517-0fd3c4b21057@xenosoft.de>
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>> Hi
>>
>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>> Hi Christophe,
>>>
>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>
>>> $ git bisect start
>>
>> As you suspect the problem to be specific to powerpc, I can do
>>
>> git bisect start -- arch/powerpc
>>
>>
>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>
>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>
>> git bisect bad powerpc-5.13-1
>> git bisect good 887f3ceb51cd3~
> I tried it but without any success.
>
> git bisect bad powerpc-5.13-1
>
> Output:
> fatal: Needed a single revision
> Bad rev input: powerpc-5.13-1
I don't understand, on my side it works. Maybe a difference between your version of git and mine.
In that case, just use the SHA corresponding to the merge:
git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
Christophe
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 9:09 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <30f559f4-b50a-de63-94e1-761022468684@csgroup.eu>
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>
>
> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>> Hi
>>>
>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>> Hi Christophe,
>>>>
>>>> Thanks for your answer but I think I don't know how it works with
>>>> the cherry-pick.
>>>>
>>>> $ git bisect start
>>>
>>> As you suspect the problem to be specific to powerpc, I can do
>>>
>>> git bisect start -- arch/powerpc
>>>
>>>
>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>
>>> You said that powerpc-5.13-1 is bad so you can narrow the search I
>>> think:
>>>
>>> git bisect bad powerpc-5.13-1
>>> git bisect good 887f3ceb51cd3~
>> I tried it but without any success.
>>
>> git bisect bad powerpc-5.13-1
>>
>> Output:
>> fatal: Needed a single revision
>> Bad rev input: powerpc-5.13-1
>
> I don't understand, on my side it works. Maybe a difference between
> your version of git and mine.
>
> In that case, just use the SHA corresponding to the merge:
>
> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>
> Christophe
Do you use a BookE machine?
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 9:11 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <c9a692b4-0ac0-d595-10fa-c3213b1518fc@xenosoft.de>
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>
>>
>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>> Hi
>>>>
>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>> Hi Christophe,
>>>>>
>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>
>>>>> $ git bisect start
>>>>
>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>
>>>> git bisect start -- arch/powerpc
>>>>
>>>>
>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>
>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>
>>>> git bisect bad powerpc-5.13-1
>>>> git bisect good 887f3ceb51cd3~
>>> I tried it but without any success.
>>>
>>> git bisect bad powerpc-5.13-1
>>>
>>> Output:
>>> fatal: Needed a single revision
>>> Bad rev input: powerpc-5.13-1
>>
>> I don't understand, on my side it works. Maybe a difference between your version of git and mine.
>>
>> In that case, just use the SHA corresponding to the merge:
>>
>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>
>> Christophe
> Do you use a BookE machine?
No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
freezes before any output.
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Nicholas Piggin @ 2021-05-04 9:13 UTC (permalink / raw)
To: Michal Suchánek; +Cc: Naveen N. Rao, linuxppc-dev
In-Reply-To: <20210503201752.GP6564@kitsune.suse.cz>
Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
>> On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
>> > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
>> > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
>> > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
>> > > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
>> > > >> GCC and clang (since 2014). It is less well tested and supported by the
>> > > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
>> > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
>> > > >> userspace.
>> > > >
>> > > > Fixes BTFID failure on BE for me and the ELF ABIv2 kernel boots.
>> > >
>> > > What's the BTFID failure? Anything we can do to fix it on the v1 ABI or
>> > > at least make it depend on BUILD_ELF_V2?
>> >
>> > Looks like symbols are prefixed with a dot in ABIv1 and BTFID tool is
>> > not aware of that. It can be disabled on ABIv1 easily.
>> >
>> > Thanks
>> >
>> > Michal
>> >
>> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> > index 678c13967580..e703c26e9b80 100644
>> > --- a/lib/Kconfig.debug
>> > +++ b/lib/Kconfig.debug
>> > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
>> > bool "Generate BTF typeinfo"
>> > depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>> > depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
>> > + depends on !PPC64 || BUILD_ELF_V2
>> > help
>> > Generate deduplicated BTF type information from DWARF debug info.
>> > Turning this on expects presence of pahole tool, which will convert
>> >
>> > >
>> > > >
>> > > > Tested-by: Michal Suchánek <msuchanek@suse.de>
>> > > >
>> > > > Also can we enable mprofile on BE now?
>> > > >
>> > > > I don't see anything endian-specific in the mprofile code at a glance
>> > > > but don't have any idea how to test it.
>> > >
>> > > AFAIK it's just a different ABI for the _mcount call so just running
>> > > some ftrace and ftrace with call graph should test it reasonably well.
>>
>> It does not crash and burn but there are some regressions from LE to BE
>> on the ftrace kernel selftest:
>>
>> --- ftraceLE.txt 2021-05-03 11:19:14.830000000 +0200
>> +++ ftraceBE.txt 2021-05-03 11:27:24.770000000 +0200
>> @@ -7,8 +7,8 @@
>> [n] Change the ringbuffer size [PASS]
>> [n] Snapshot and tracing setting [PASS]
>> [n] trace_pipe and trace_marker [PASS]
>> -[n] Test ftrace direct functions against tracers [UNRESOLVED]
>> -[n] Test ftrace direct functions against kprobes [UNRESOLVED]
>> +[n] Test ftrace direct functions against tracers [FAIL]
>> +[n] Test ftrace direct functions against kprobes [FAIL]
>> [n] Generic dynamic event - add/remove kprobe events [PASS]
>> [n] Generic dynamic event - add/remove synthetic events [PASS]
>> [n] Generic dynamic event - selective clear (compatibility) [PASS]
>> @@ -16,10 +16,10 @@
>> [n] event tracing - enable/disable with event level files [PASS]
>> [n] event tracing - restricts events based on pid notrace filtering [PASS]
>> [n] event tracing - restricts events based on pid [PASS]
>> -[n] event tracing - enable/disable with subsystem level files [PASS]
>> +[n] event tracing - enable/disable with subsystem level files [FAIL]
>> [n] event tracing - enable/disable with top level files [PASS]
>> -[n] Test trace_printk from module [UNRESOLVED]
>> -[n] ftrace - function graph filters with stack tracer [PASS]
>> +[n] Test trace_printk from module [FAIL]
>> +[n] ftrace - function graph filters with stack tracer [FAIL]
>> [n] ftrace - function graph filters [PASS]
>> [n] ftrace - function trace with cpumask [PASS]
>> [n] ftrace - test for function event triggers [PASS]
>> @@ -27,7 +27,7 @@
>> [n] ftrace - function pid notrace filters [PASS]
>> [n] ftrace - function pid filters [PASS]
>> [n] ftrace - stacktrace filter command [PASS]
>> -[n] ftrace - function trace on module [UNRESOLVED]
>> +[n] ftrace - function trace on module [FAIL]
>> [n] ftrace - function profiler with function tracing [PASS]
>> [n] ftrace - function profiling [PASS]
>> [n] ftrace - test reading of set_ftrace_filter [PASS]
>> @@ -44,10 +44,10 @@
>> [n] Kprobe event argument syntax [PASS]
>> [n] Kprobe dynamic event with arguments [PASS]
>> [n] Kprobes event arguments with types [PASS]
>> -[n] Kprobe event user-memory access [UNSUPPORTED]
>> +[n] Kprobe event user-memory access [FAIL]
>> [n] Kprobe event auto/manual naming [PASS]
>> [n] Kprobe dynamic event with function tracer [PASS]
>> -[n] Kprobe dynamic event - probing module [UNRESOLVED]
>> +[n] Kprobe dynamic event - probing module [FAIL]
>> [n] Create/delete multiprobe on kprobe event [PASS]
>> [n] Kprobe event parser error log check [PASS]
>> [n] Kretprobe dynamic event with arguments [PASS]
>> @@ -57,11 +57,11 @@
>> [n] Kprobe events - probe points [PASS]
>> [n] Kprobe dynamic event - adding and removing [PASS]
>> [n] Uprobe event parser error log check [PASS]
>> -[n] test for the preemptirqsoff tracer [UNSUPPORTED]
>> -[n] Meta-selftest: Checkbashisms [UNRESOLVED]
>> +[n] test for the preemptirqsoff tracer [FAIL]
>> +[n] Meta-selftest: Checkbashisms [FAIL]
>> [n] Test wakeup RT tracer [PASS]
>> [n] Test wakeup tracer [PASS]
>> -[n] event trigger - test inter-event histogram trigger expected fail actions [XFAIL]
>> +[n] event trigger - test inter-event histogram trigger expected fail actions [FAIL]
>> [n] event trigger - test field variable support [PASS]
>> [n] event trigger - test inter-event combined histogram trigger [PASS]
>> [n] event trigger - test multiple actions on hist trigger [PASS]
>> @@ -96,7 +96,8 @@
>> [n] (instance) event tracing - enable/disable with event level files [PASS]
>> [n] (instance) event tracing - restricts events based on pid notrace filtering [PASS]
>> [n] (instance) event tracing - restricts events based on pid [PASS]
>> -[n] (instance) event tracing - enable/disable with subsystem level files [PASS]
>> +[n] (instance) event tracing - enable/disable with subsystem level files [FAIL]
>> +rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource busy
>> [n] (instance) ftrace - test for function event triggers [PASS]
>> [n] (instance) ftrace - function pid notrace filters [PASS]
>> [n] (instance) ftrace - function pid filters [PASS]
>>
>> I needed to add a test timeout to get this far because
>> "event tracing - enable/disable with subsystem level files" gets stuck.
>
> There is some regression from mprofile on BE ABIv2
>
> --- ftraceBEv2.txt 2021-05-03 18:11:01.100000000 +0200
> +++ ftraceBE.mprofile.txt 2021-05-03 11:27:24.770000000 +0200
> @@ -19,7 +19,7 @@
> [n] event tracing - enable/disable with subsystem level files [FAIL]
> [n] event tracing - enable/disable with top level files [PASS]
> [n] Test trace_printk from module [FAIL]
> -[n] ftrace - function graph filters with stack tracer [PASS]
> +[n] ftrace - function graph filters with stack tracer [FAIL]
> [n] ftrace - function graph filters [PASS]
> [n] ftrace - function trace with cpumask [PASS]
> [n] ftrace - test for function event triggers [PASS]
> @@ -31,7 +31,7 @@
> [n] ftrace - function profiler with function tracing [PASS]
> [n] ftrace - function profiling [PASS]
> [n] ftrace - test reading of set_ftrace_filter [PASS]
> -[n] ftrace - Max stack tracer [PASS]
> +[n] ftrace - Max stack tracer [FAIL]
> [n] ftrace - test for function traceon/off triggers [PASS]
> [n] ftrace - test tracing error log support [PASS]
> [n] Test creation and deletion of trace instances while setting an event [PASS]
Hmm, I don't see an obvious case where the stack layout is based on
BE when it should be using ELF ABI version, or ftrace_64_mprofile.S
depends on LE. +Naveen
>
> but generally the ftrace on BE is broken overall. The test
> "event tracing - enable/disable with subsystem level files" gets stuck
> and has to be killed by timeout. Running the testsuite twice the test
> "Basic test for tracers" locks up the machine regardless of using
> mprofile. The ABIV1 is even much worse with the exception of
> "(instance) event tracing - enable/disable with subsystem level files"
> which regresses on BE ABIv2 in general.
Wow it has fixed quite a few! That event tracing one hardly looks like
a difficult test, hopefully should be something trivial.
Thanks for testing.
Thanks,
Nick
>
> --- ftraceBEv1.txt 2021-05-03 22:09:10.690000000 +0200
> +++ ftraceBEv2.txt 2021-05-03 18:11:01.100000000 +0200
> @@ -9,10 +9,10 @@
> [n] trace_pipe and trace_marker [PASS]
> [n] Test ftrace direct functions against tracers [FAIL]
> [n] Test ftrace direct functions against kprobes [FAIL]
> -[n] Generic dynamic event - add/remove kprobe events [FAIL]
> +[n] Generic dynamic event - add/remove kprobe events [PASS]
> [n] Generic dynamic event - add/remove synthetic events [PASS]
> -[n] Generic dynamic event - selective clear (compatibility) [FAIL]
> -[n] Generic dynamic event - generic clear event [FAIL]
> +[n] Generic dynamic event - selective clear (compatibility) [PASS]
> +[n] Generic dynamic event - generic clear event [PASS]
> [n] event tracing - enable/disable with event level files [PASS]
> [n] event tracing - restricts events based on pid notrace filtering [PASS]
> [n] event tracing - restricts events based on pid [PASS]
> @@ -23,39 +23,39 @@
> [n] ftrace - function graph filters [PASS]
> [n] ftrace - function trace with cpumask [PASS]
> [n] ftrace - test for function event triggers [PASS]
> -[n] ftrace - function glob filters [FAIL]
> +[n] ftrace - function glob filters [PASS]
> [n] ftrace - function pid notrace filters [PASS]
> [n] ftrace - function pid filters [PASS]
> [n] ftrace - stacktrace filter command [PASS]
> [n] ftrace - function trace on module [FAIL]
> [n] ftrace - function profiler with function tracing [PASS]
> [n] ftrace - function profiling [PASS]
> -[n] ftrace - test reading of set_ftrace_filter [FAIL]
> +[n] ftrace - test reading of set_ftrace_filter [PASS]
> [n] ftrace - Max stack tracer [PASS]
> [n] ftrace - test for function traceon/off triggers [PASS]
> [n] ftrace - test tracing error log support [PASS]
> [n] Test creation and deletion of trace instances while setting an event [PASS]
> [n] Test creation and deletion of trace instances [PASS]
> -[n] Kprobe dynamic event - adding and removing [FAIL]
> -[n] Kprobe dynamic event - busy event check [FAIL]
> -[n] Kprobe dynamic event with arguments [FAIL]
> -[n] Kprobe event with comm arguments [FAIL]
> -[n] Kprobe event string type argument [FAIL]
> -[n] Kprobe event symbol argument [FAIL]
> -[n] Kprobe event argument syntax [FAIL]
> -[n] Kprobes event arguments with types [FAIL]
> +[n] Kprobe dynamic event - adding and removing [PASS]
> +[n] Kprobe dynamic event - busy event check [PASS]
> +[n] Kprobe event with comm arguments [PASS]
> +[n] Kprobe event string type argument [PASS]
> +[n] Kprobe event symbol argument [PASS]
> +[n] Kprobe event argument syntax [PASS]
> +[n] Kprobe dynamic event with arguments [PASS]
> +[n] Kprobes event arguments with types [PASS]
> [n] Kprobe event user-memory access [FAIL]
> [n] Kprobe event auto/manual naming [PASS]
> -[n] Kprobe dynamic event with function tracer [FAIL]
> +[n] Kprobe dynamic event with function tracer [PASS]
> [n] Kprobe dynamic event - probing module [FAIL]
> -[n] Create/delete multiprobe on kprobe event [FAIL]
> -[n] Kprobe event parser error log check [FAIL]
> -[n] Kretprobe dynamic event with arguments [FAIL]
> -[n] Kretprobe dynamic event with maxactive [FAIL]
> -[n] Kretprobe %return suffix test [FAIL]
> -[n] Register/unregister many kprobe events [FAIL]
> -[n] Kprobe events - probe points [FAIL]
> -[n] Kprobe dynamic event - adding and removing [FAIL]
> +[n] Create/delete multiprobe on kprobe event [PASS]
> +[n] Kprobe event parser error log check [PASS]
> +[n] Kretprobe dynamic event with arguments [PASS]
> +[n] Kretprobe dynamic event with maxactive [PASS]
> +[n] Kretprobe %return suffix test [PASS]
> +[n] Register/unregister many kprobe events [PASS]
> +[n] Kprobe events - probe points [PASS]
> +[n] Kprobe dynamic event - adding and removing [PASS]
> [n] Uprobe event parser error log check [PASS]
> [n] test for the preemptirqsoff tracer [FAIL]
> [n] Meta-selftest: Checkbashisms [FAIL]
> @@ -96,7 +96,8 @@
> [n] (instance) event tracing - enable/disable with event level files [PASS]
> [n] (instance) event tracing - restricts events based on pid notrace filtering [PASS]
> [n] (instance) event tracing - restricts events based on pid [PASS]
> -[n] (instance) event tracing - enable/disable with subsystem level files [PASS]
> +[n] (instance) event tracing - enable/disable with subsystem level files [FAIL]
> +rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.lxCI5k': Device or resource busy
> [n] (instance) ftrace - test for function event triggers [PASS]
> [n] (instance) ftrace - function pid notrace filters [PASS]
> [n] (instance) ftrace - function pid filters [PASS]
>
>
> Thanks
>
> Michal
>
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes
From: Nicholas Piggin @ 2021-05-04 9:16 UTC (permalink / raw)
To: Joel Stanley; +Cc: linuxppc-dev
In-Reply-To: <CACPK8XekEXgqA1bML6A+NbsshzsLe+pLTzGJzRLdC+QKrV5T9Q@mail.gmail.com>
Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> On Mon, 3 May 2021 at 13:04, Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> These aren't necessarily POWER9 only, and it's not to say some new
>> vulnerability may not get discovered on other processors for which
>> we would like the flexibility of having the workaround enabled by
>> firmware.
>>
>> Remove the restriction that they only apply to POWER9.
>
> I was wondering how these worked which led me to reviewing your patch.
> From what I could see, these are enabled by default (SEC_FTR_DEFAULT
> in arch/powerpc/include/asm/security_features.h), so unless all
> non-POWER9 machines have set the "please don't" bit in their firmware
> this patch will enable the feature for those machines. Is that what
> you wanted?
Yes. POWER7/8 should be affected (it's similar mechanism that requires
the meltdown RFI flush, which those processors need).
POWER10 we haven't released a bare metal firmware with the right bits
yet. Not urgent at the moment but wouldn't hurt to specify them and
add the Linux code for them.
Thanks,
Nick
>
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/platforms/powernv/setup.c | 9 ---------
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
>> index a8db3f153063..6ec67223f8c7 100644
>> --- a/arch/powerpc/platforms/powernv/setup.c
>> +++ b/arch/powerpc/platforms/powernv/setup.c
>> @@ -122,15 +122,6 @@ static void pnv_setup_security_mitigations(void)
>> type = L1D_FLUSH_ORI;
>> }
>>
>> - /*
>> - * If we are non-Power9 bare metal, we don't need to flush on kernel
>> - * entry or after user access: they fix a P9 specific vulnerability.
>> - */
>> - if (!pvr_version_is(PVR_POWER9)) {
>> - security_ftr_clear(SEC_FTR_L1D_FLUSH_ENTRY);
>> - security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
>> - }
>> -
>> enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \
>> (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) || \
>> security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
>> --
>> 2.23.0
>>
>
^ permalink raw reply
* [PATCH v4] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-05-04 9:20 UTC (permalink / raw)
To: mpe, benh, paulus
Cc: nathanl, Aneesh Kumar K . V, linuxppc-dev, linux-kernel,
Tyrel Datwyler
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is caught by the kernel, but the memory's node is updated because
there is no way to move a memory block between nodes.
If later a memory block is added or removed, drmem_update_dt() is called
and it is overwriting the DT node to match the added or removed LMB. But
the LMB's associativity node has not been updated after the DT node update
and thus the node is overwritten by the Linux's topology instead of the
hypervisor one.
Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
updated to force an update of the LMB's associativity. However, ignore the
call to that hook when the update has been triggered by drmem_update_dt().
Because, in that case, the LMB tree has been used to set the DT property
and thus it doesn't need to be updated back. Since drmem_update_dt() is
called under the protection of the device_hotplug_lock and the hook is
called in the same context, use a simple boolean variable to detect that
call.
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
V4:
- Prevent the LMB to be updated back in the case the request came from the
LMB tree's update.
V3:
- Check rd->dn->name instead of rd->dn->full_name
V2:
- Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
introducing a new hook mechanism.
---
arch/powerpc/include/asm/drmem.h | 1 +
arch/powerpc/mm/drmem.c | 46 +++++++++++++++++++
.../platforms/pseries/hotplug-memory.c | 4 ++
3 files changed, 51 insertions(+)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index bf2402fed3e0..4265d5e95c2c 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -111,6 +111,7 @@ int drmem_update_dt(void);
int __init
walk_drmem_lmbs_early(unsigned long node, void *data,
int (*func)(struct drmem_lmb *, const __be32 **, void *));
+void drmem_update_lmbs(struct property *prop);
#endif
static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 9af3832c9d8d..22197b18d85e 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -18,6 +18,7 @@ static int n_root_addr_cells, n_root_size_cells;
static struct drmem_lmb_info __drmem_info;
struct drmem_lmb_info *drmem_info = &__drmem_info;
+static bool in_drmem_update;
u64 drmem_lmb_memory_max(void)
{
@@ -178,6 +179,11 @@ int drmem_update_dt(void)
if (!memory)
return -1;
+ /*
+ * Set in_drmem_update to prevent the notifier callback to process the
+ * DT property back since the change is coming from the LMB tree.
+ */
+ in_drmem_update = true;
prop = of_find_property(memory, "ibm,dynamic-memory", NULL);
if (prop) {
rc = drmem_update_dt_v1(memory, prop);
@@ -186,6 +192,7 @@ int drmem_update_dt(void)
if (prop)
rc = drmem_update_dt_v2(memory, prop);
}
+ in_drmem_update = false;
of_node_put(memory);
return rc;
@@ -307,6 +314,45 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
return ret;
}
+/*
+ * Update the LMB associativity index.
+ */
+static int update_lmb(struct drmem_lmb *updated_lmb,
+ __maybe_unused const __be32 **usm,
+ __maybe_unused void *data)
+{
+ struct drmem_lmb *lmb;
+
+ for_each_drmem_lmb(lmb) {
+ if (lmb->drc_index != updated_lmb->drc_index)
+ continue;
+
+ lmb->aa_index = updated_lmb->aa_index;
+ break;
+ }
+ return 0;
+}
+
+/*
+ * Update the LMB associativity index.
+ *
+ * This needs to be called when the hypervisor is updating the
+ * dynamic-reconfiguration-memory node property.
+ */
+void drmem_update_lmbs(struct property *prop)
+{
+ /*
+ * Don't update the LMBs if triggered by the update done in
+ * drmem_update_dt(), the LMB values have been used to the update the DT
+ * property in that case.
+ */
+ if (in_drmem_update)
+ return;
+ if (!strcmp(prop->name, "ibm,dynamic-memory"))
+ __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
+ else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
+ __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
+}
#endif
static int init_drmem_lmb_size(struct device_node *dn)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8377f1f7c78e..672ffbee2e78 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
case OF_RECONFIG_DETACH_NODE:
err = pseries_remove_mem_node(rd->dn);
break;
+ case OF_RECONFIG_UPDATE_PROPERTY:
+ if (!strcmp(rd->dn->name,
+ "ibm,dynamic-reconfiguration-memory"))
+ drmem_update_lmbs(rd->prop);
}
return notifier_from_errno(err);
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Michal Suchánek @ 2021-05-04 9:22 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Linus Torvalds, Joe Perches, Ben Dooks, Palmer Dabbelt,
Paul Walmsley, Miguel Ojeda, Paul Mackerras, linux-riscv,
linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <CANiq72mk84uay--BWOLT4zF12-rat9erohKazB8SpTPoVCTX1A@mail.gmail.com>
On Tue, May 04, 2021 at 10:38:32AM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 9:57 AM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> >
> > Some of us are a bit stuck as either customer refuses to upgrade
> > their build infrastructure or has paid for some old but safety
> > blessed version of gcc. These often lag years behind the recent
> > gcc releases :(
>
> In those scenarios, why do you need to build mainline? Aren't your
> customers using longterm or frozen kernels? If they are paying for
> certified GCC images, aren't they already paying for supported kernel
> images from some vendor too?
>
> I understand where you are coming from -- I have also dealt with
> projects/machines running ancient, unsupported software/toolchains for
> various reasons; but nobody expected upstream (and in particular the
> mainline kernel source) to support them. In the cases I experienced,
> those use cases require not touching anything at all, and when the
> time came of doing so, everything would be updated at once,
> re-certified/validated as needed and frozen again.
Except it makes answering the question "Is this bug we see on this
ancient system still present in upstream?" needlessly more difficult to
answer.
Sure, throwing out old compiler versions that are known to cause
problems makes sense. Updating to latest just because much less so.
One of the selling point of C in general and gcc in particular is
stability. If we need the latest compiler we can as well rewrite the
kernel in Rust which has a required update cycle of a few months.
Because some mainline kernel features rely on bleeding edge tools I end
up building mainline with current tools anyway but if you do not need
BTF or whatever other latest gimmick older toolchains should do.
Thanks
Michal
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 9:46 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <3b7daea5-7b2b-a089-0427-3becb986b6f5@csgroup.eu>
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>
>
> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>
>>>
>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>> Hi
>>>>>
>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>> Hi Christophe,
>>>>>>
>>>>>> Thanks for your answer but I think I don't know how it works with
>>>>>> the cherry-pick.
>>>>>>
>>>>>> $ git bisect start
>>>>>
>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>
>>>>> git bisect start -- arch/powerpc
>>>>>
>>>>>
>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>
>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I
>>>>> think:
>>>>>
>>>>> git bisect bad powerpc-5.13-1
>>>>> git bisect good 887f3ceb51cd3~
>>>> I tried it but without any success.
>>>>
>>>> git bisect bad powerpc-5.13-1
>>>>
>>>> Output:
>>>> fatal: Needed a single revision
>>>> Bad rev input: powerpc-5.13-1
>>>
>>> I don't understand, on my side it works. Maybe a difference between
>>> your version of git and mine.
>>>
>>> In that case, just use the SHA corresponding to the merge:
>>>
>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>
>>> Christophe
>> Do you use a BookE machine?
>
> No I don't unfortunately, and I have tried booting in QEMU a kernel
> built with your config, but it freezes before any output.
You can use my kernels and distributions.
Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
Download size: 4.1 GB
MD5 checksum: 1784ca69651531522161498720a89414
Default username and password:
Username: amigaone
Password: amigaone
Root Password: amigaone
You can start the MATE desktop with "startx".
Download MintPPC (Debian Sid) PPC32:
http://www.xenosoft.de/MintPPC32-X5000.tar.gz
MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654
The password for both 'root' and 'mintppc' is 'mintppc'.
Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500
QEMU machine without the bad commit:
http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
Download git kernel for the AmigaOne X5000 and for the virtual e5500
QEMU machine with the bad commit:
http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz
QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu
e5500 -enable-kvm -m 1024 -kernel uImage -drive
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda"
-device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci
-device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4
QEMU command for Fedora 28 without KVM and with VNC connect:
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive
format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0
-device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device
virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device
virtio-keyboard-pci -smp 4 -vnc :1
QEMU command for MintPPC without KVM and with VNC connect:
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw
root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device
usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christophe Leroy @ 2021-05-04 9:49 UTC (permalink / raw)
To: Christian Zigotzky, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <1502fb22-680c-7393-238c-f82570806717@xenosoft.de>
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>
>>
>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>
>>>>
>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>> Hi
>>>>>>
>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>> Hi Christophe,
>>>>>>>
>>>>>>> Thanks for your answer but I think I don't know how it works with the cherry-pick.
>>>>>>>
>>>>>>> $ git bisect start
>>>>>>
>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>
>>>>>> git bisect start -- arch/powerpc
>>>>>>
>>>>>>
>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>
>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search I think:
>>>>>>
>>>>>> git bisect bad powerpc-5.13-1
>>>>>> git bisect good 887f3ceb51cd3~
>>>>> I tried it but without any success.
>>>>>
>>>>> git bisect bad powerpc-5.13-1
>>>>>
>>>>> Output:
>>>>> fatal: Needed a single revision
>>>>> Bad rev input: powerpc-5.13-1
>>>>
>>>> I don't understand, on my side it works. Maybe a difference between your version of git and mine.
>>>>
>>>> In that case, just use the SHA corresponding to the merge:
>>>>
>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>
>>>> Christophe
>>> Do you use a BookE machine?
>>
>> No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it
>> freezes before any output.
> You can use my kernels and distributions.
>
Ok, I'll see if I can do something with them.
In the meantime, have you been able to bisect ?
Thanks
Christophe
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 10:07 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <6a322f04-a81e-ae31-1425-19fda9307b23@csgroup.eu>
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>
>
> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>
>>>
>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>
>>>>>
>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>> Hi Christophe,
>>>>>>>>
>>>>>>>> Thanks for your answer but I think I don't know how it works
>>>>>>>> with the cherry-pick.
>>>>>>>>
>>>>>>>> $ git bisect start
>>>>>>>
>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>
>>>>>>> git bisect start -- arch/powerpc
>>>>>>>
>>>>>>>
>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>
>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the search
>>>>>>> I think:
>>>>>>>
>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>> I tried it but without any success.
>>>>>>
>>>>>> git bisect bad powerpc-5.13-1
>>>>>>
>>>>>> Output:
>>>>>> fatal: Needed a single revision
>>>>>> Bad rev input: powerpc-5.13-1
>>>>>
>>>>> I don't understand, on my side it works. Maybe a difference
>>>>> between your version of git and mine.
>>>>>
>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>
>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>
>>>>> Christophe
>>>> Do you use a BookE machine?
>>>
>>> No I don't unfortunately, and I have tried booting in QEMU a kernel
>>> built with your config, but it freezes before any output.
>> You can use my kernels and distributions.
>>
>
> Ok, I'll see if I can do something with them.
>
> In the meantime, have you been able to bisect ?
>
> Thanks
> Christophe
I am bisecting currently.
$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca
From: Nicholas Piggin @ 2021-05-04 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f38728dbe96df5fef84c868640def5f6d7c114bc.1620060357.git.christophe.leroy@csgroup.eu>
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
> PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
> PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
> PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
> by ASM code.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH,
KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
PPC_DBELL_MSGTYPE I think. While we're cleaning it up.
>
> Remove them.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/asm-offsets.c | 24 ------------------------
> 1 file changed, 24 deletions(-)
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index 28af4efb4587..419ab4a89114 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -197,7 +197,6 @@ int main(void)
> OFFSET(ICACHEL1LOGBLOCKSIZE, ppc64_caches, l1i.log_block_size);
> OFFSET(ICACHEL1BLOCKSPERPAGE, ppc64_caches, l1i.blocks_per_page);
> /* paca */
> - DEFINE(PACA_SIZE, sizeof(struct paca_struct));
> OFFSET(PACAPACAINDEX, paca_struct, paca_index);
> OFFSET(PACAPROCSTART, paca_struct, cpu_start);
> OFFSET(PACAKSAVE, paca_struct, kstack);
> @@ -212,15 +211,6 @@ int main(void)
> OFFSET(PACAIRQSOFTMASK, paca_struct, irq_soft_mask);
> OFFSET(PACAIRQHAPPENED, paca_struct, irq_happened);
> OFFSET(PACA_FTRACE_ENABLED, paca_struct, ftrace_enabled);
> -#ifdef CONFIG_PPC_BOOK3S
> - OFFSET(PACACONTEXTID, paca_struct, mm_ctx_id);
> -#ifdef CONFIG_PPC_MM_SLICES
> - OFFSET(PACALOWSLICESPSIZE, paca_struct, mm_ctx_low_slices_psize);
> - OFFSET(PACAHIGHSLICEPSIZE, paca_struct, mm_ctx_high_slices_psize);
> - OFFSET(PACA_SLB_ADDR_LIMIT, paca_struct, mm_ctx_slb_addr_limit);
> - DEFINE(MMUPSIZEDEFSIZE, sizeof(struct mmu_psize_def));
> -#endif /* CONFIG_PPC_MM_SLICES */
> -#endif
>
> #ifdef CONFIG_PPC_BOOK3E
> OFFSET(PACAPGD, paca_struct, pgd);
> @@ -241,21 +231,9 @@ int main(void)
> #endif /* CONFIG_PPC_BOOK3E */
>
> #ifdef CONFIG_PPC_BOOK3S_64
> - OFFSET(PACASLBCACHE, paca_struct, slb_cache);
> - OFFSET(PACASLBCACHEPTR, paca_struct, slb_cache_ptr);
> - OFFSET(PACASTABRR, paca_struct, stab_rr);
> - OFFSET(PACAVMALLOCSLLP, paca_struct, vmalloc_sllp);
> -#ifdef CONFIG_PPC_MM_SLICES
> - OFFSET(MMUPSIZESLLP, mmu_psize_def, sllp);
> -#else
> - OFFSET(PACACONTEXTSLLP, paca_struct, mm_ctx_sllp);
> -#endif /* CONFIG_PPC_MM_SLICES */
> OFFSET(PACA_EXGEN, paca_struct, exgen);
> OFFSET(PACA_EXMC, paca_struct, exmc);
> OFFSET(PACA_EXNMI, paca_struct, exnmi);
> -#ifdef CONFIG_PPC_PSERIES
> - OFFSET(PACALPPACAPTR, paca_struct, lppaca_ptr);
> -#endif
> OFFSET(PACA_SLBSHADOWPTR, paca_struct, slb_shadow_ptr);
> OFFSET(SLBSHADOW_STACKVSID, slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid);
> OFFSET(SLBSHADOW_STACKESID, slb_shadow, save_area[SLB_NUM_BOLTED - 1].esid);
> @@ -264,9 +242,7 @@ int main(void)
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> OFFSET(PACA_PMCINUSE, paca_struct, pmcregs_in_use);
> #endif
> - OFFSET(LPPACA_DTLIDX, lppaca, dtl_idx);
> OFFSET(LPPACA_YIELDCOUNT, lppaca, yield_count);
> - OFFSET(PACA_DTL_RIDX, paca_struct, dtl_ridx);
> #endif /* CONFIG_PPC_BOOK3S_64 */
> OFFSET(PACAEMERGSP, paca_struct, emergency_sp);
> #ifdef CONFIG_PPC_BOOK3S_64
> --
> 2.25.0
>
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/paca: Remove mm_ctx_id and mm_ctx_slb_addr_limit
From: Nicholas Piggin @ 2021-05-04 10:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cc8bc507cce433bc9bbfe86f6fc22b29ce21d461.1620060357.git.christophe.leroy@csgroup.eu>
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> mm_ctx_id and mm_ctx_slb_addr_limit are not used anymore.
>
> Remove them.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/paca.h | 2 --
> arch/powerpc/kernel/paca.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index ec18ac818e3a..ecc8d792a431 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -149,11 +149,9 @@ struct paca_struct {
> #endif /* CONFIG_PPC_BOOK3E */
>
> #ifdef CONFIG_PPC_BOOK3S
> - mm_context_id_t mm_ctx_id;
> #ifdef CONFIG_PPC_MM_SLICES
> unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
> unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
> - unsigned long mm_ctx_slb_addr_limit;
> #else
> u16 mm_ctx_user_psize;
> u16 mm_ctx_sllp;
> diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
> index 7f5aae3c387d..9bd30cac852b 100644
> --- a/arch/powerpc/kernel/paca.c
> +++ b/arch/powerpc/kernel/paca.c
> @@ -346,10 +346,8 @@ void copy_mm_to_paca(struct mm_struct *mm)
> #ifdef CONFIG_PPC_BOOK3S
> mm_context_t *context = &mm->context;
>
> - get_paca()->mm_ctx_id = context->id;
> #ifdef CONFIG_PPC_MM_SLICES
> VM_BUG_ON(!mm_ctx_slb_addr_limit(context));
> - get_paca()->mm_ctx_slb_addr_limit = mm_ctx_slb_addr_limit(context);
> memcpy(&get_paca()->mm_ctx_low_slices_psize, mm_ctx_low_slices(context),
> LOW_SLICE_ARRAY_SZ);
> memcpy(&get_paca()->mm_ctx_high_slices_psize, mm_ctx_high_slices(context),
> --
> 2.25.0
>
>
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code
From: Naveen N. Rao @ 2021-05-04 10:25 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <1619832142.gw4mrldjdp.astroid@bobo.none>
Nicholas Piggin wrote:
> Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
>> Nicholas Piggin wrote:
>>> + *
>>> + * H_CONFER from spin locks must be treated separately though and use _notrace
>>> + * plpar_hcall variants, see yield_to_preempted().
>>> */
>>> static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
>>>
>>> @@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
>>>
>>> depth = this_cpu_ptr(&hcall_trace_depth);
>>>
>>> - if (*depth)
>>> + if (WARN_ON_ONCE(*depth))
>>> goto out;
>>
>> I don't think this will be helpful. The hcall trace depth tracking is
>> for the tracepoint and I suspect that this warning will be triggered
>> quite easily. Since we have recursion protection, I don't think we
>> should warn here.
>
> What would trigger recursion?
The trace code that this protects: trace_hcall_entry(). The tracing code
itself can end up doing a hcall as we see in the first patch in this
series:
plpar_hcall_norets_trace+0x34/0x8c (unreliable)
__pv_queued_spin_lock_slowpath+0x684/0x710
trace_clock_global+0x148/0x150
ring_buffer_lock_reserve+0x12c/0x630
trace_event_buffer_lock_reserve+0x80/0x220
trace_event_buffer_reserve+0x7c/0xd0
trace_event_raw_event_hcall_entry+0x68/0x150
__trace_hcall_entry+0x160/0x180
There is also a comment aroung hcall_trace_depth that mentions this:
/*
* Since the tracing code might execute hcalls we need to guard against
* recursion. One example of this are spinlocks calling H_YIELD on
* shared processor partitions.
*/
Thanks,
Naveen
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Nicholas Piggin @ 2021-05-04 10:27 UTC (permalink / raw)
To: Michal Suchánek, Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <20210503143841.GN6564@kitsune.suse.cz>
Excerpts from Michal Suchánek's message of May 4, 2021 12:38 am:
> On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
>> Should this add a tag to the module vermagic?
Good question.
>
> Would the modues link even if the vermagic was not changed?
>
> I suppose something like this might do it.
Yeah I don't know how robust the loader would be to a mismatch. We could
add this patch.
Thanks,
Nick
>
> Thanks
>
> Michal
>
> diff --git a/arch/powerpc/include/asm/vermagic.h b/arch/powerpc/include/asm/vermagic.h
> index b054a8576e5d..3fdaacd7a743 100644
> --- a/arch/powerpc/include/asm/vermagic.h
> +++ b/arch/powerpc/include/asm/vermagic.h
> @@ -14,7 +14,14 @@
> #define MODULE_ARCH_VERMAGIC_RELOCATABLE ""
> #endif
>
> +
> +#ifdef CONFIG_PPC64_BUILD_BIG_ENDIAN_ELF_V2_ABI
> +#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI "abi-elfv2 "
> +#else
> +#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI ""
> +#endif
> +
> #define MODULE_ARCH_VERMAGIC \
> - MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE
> + MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE MODULE_ARCH_VERMAGIC_ELF_V2_ABI
>
> #endif /* _ASM_VERMAGIC_H */
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca
From: Christophe Leroy @ 2021-05-04 10:40 UTC (permalink / raw)
To: Nicholas Piggin, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1620121538.q0b7uiea5y.astroid@bobo.none>
Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
>> PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
>> PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
>> PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
>> PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
>> by ASM code.
>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>
> Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
> TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH,
> KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
> PPC_DBELL_MSGTYPE I think. While we're cleaning it up.
Yes, thanks for checking.
I think we can safely remove KUAP.
But we can't remove EXC_LVL_SIZE, it is used in kernel/head_booke.h which is probably included in
head_44x.S and head_fsl_booke.S
Christophe
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code
From: Nicholas Piggin @ 2021-05-04 10:45 UTC (permalink / raw)
To: linuxppc-dev, Naveen N. Rao
In-Reply-To: <1620123377.d2jb7v70z0.naveen@linux.ibm.com>
Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:
> Nicholas Piggin wrote:
>> Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
>>> Nicholas Piggin wrote:
>>>> + *
>>>> + * H_CONFER from spin locks must be treated separately though and use _notrace
>>>> + * plpar_hcall variants, see yield_to_preempted().
>>>> */
>>>> static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
>>>>
>>>> @@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
>>>>
>>>> depth = this_cpu_ptr(&hcall_trace_depth);
>>>>
>>>> - if (*depth)
>>>> + if (WARN_ON_ONCE(*depth))
>>>> goto out;
>>>
>>> I don't think this will be helpful. The hcall trace depth tracking is
>>> for the tracepoint and I suspect that this warning will be triggered
>>> quite easily. Since we have recursion protection, I don't think we
>>> should warn here.
>>
>> What would trigger recursion?
>
> The trace code that this protects: trace_hcall_entry(). The tracing code
> itself can end up doing a hcall as we see in the first patch in this
> series:
> plpar_hcall_norets_trace+0x34/0x8c (unreliable)
> __pv_queued_spin_lock_slowpath+0x684/0x710
> trace_clock_global+0x148/0x150
> ring_buffer_lock_reserve+0x12c/0x630
> trace_event_buffer_lock_reserve+0x80/0x220
> trace_event_buffer_reserve+0x7c/0xd0
> trace_event_raw_event_hcall_entry+0x68/0x150
> __trace_hcall_entry+0x160/0x180
>
>
> There is also a comment aroung hcall_trace_depth that mentions this:
>
> /*
> * Since the tracing code might execute hcalls we need to guard against
> * recursion. One example of this are spinlocks calling H_YIELD on
> * shared processor partitions.
> */
Right but since fixing those, my thought is we better not cause more
any recursion, so we should fix anything that does.
Thanks,
Nick
^ permalink raw reply
* Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1
From: Christian Zigotzky @ 2021-05-04 11:02 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: Darren Stevens, linuxppc-dev, mad skateman, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <f253fc33-daa1-e668-31b3-593991531ffb@xenosoft.de>
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
> Am 04.05.21 um 11:49 schrieb Christophe Leroy:
>>
>>
>> Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
>>> Am 04.05.21 um 11:11 schrieb Christophe Leroy:
>>>>
>>>>
>>>> Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
>>>>> Am 04.05.21 um 10:58 schrieb Christophe Leroy:
>>>>>>
>>>>>>
>>>>>> Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
>>>>>>> On 04 May 2021 at 09:47am, Christophe Leroy wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
>>>>>>>>> Hi Christophe,
>>>>>>>>>
>>>>>>>>> Thanks for your answer but I think I don't know how it works
>>>>>>>>> with the cherry-pick.
>>>>>>>>>
>>>>>>>>> $ git bisect start
>>>>>>>>
>>>>>>>> As you suspect the problem to be specific to powerpc, I can do
>>>>>>>>
>>>>>>>> git bisect start -- arch/powerpc
>>>>>>>>
>>>>>>>>
>>>>>>>>> $ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
>>>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>>>
>>>>>>>> You said that powerpc-5.13-1 is bad so you can narrow the
>>>>>>>> search I think:
>>>>>>>>
>>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>> git bisect good 887f3ceb51cd3~
>>>>>>> I tried it but without any success.
>>>>>>>
>>>>>>> git bisect bad powerpc-5.13-1
>>>>>>>
>>>>>>> Output:
>>>>>>> fatal: Needed a single revision
>>>>>>> Bad rev input: powerpc-5.13-1
>>>>>>
>>>>>> I don't understand, on my side it works. Maybe a difference
>>>>>> between your version of git and mine.
>>>>>>
>>>>>> In that case, just use the SHA corresponding to the merge:
>>>>>>
>>>>>> git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>>
>>>>>> Christophe
>>>>> Do you use a BookE machine?
>>>>
>>>> No I don't unfortunately, and I have tried booting in QEMU a kernel
>>>> built with your config, but it freezes before any output.
>>> You can use my kernels and distributions.
>>>
>>
>> Ok, I'll see if I can do something with them.
>>
>> In the meantime, have you been able to bisect ?
>>
>> Thanks
>> Christophe
> I am bisecting currently.
>
> $ git bisect start -- arch/powerpc
> $ git bisect good 887f3ceb51cd3~
> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot
stops after loading the dtb and uImage file. I can't solve 2 issues with
bisecting at the same time.
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Arnd Bergmann @ 2021-05-04 12:07 UTC (permalink / raw)
To: Arnd Bergmann, Matthew Wilcox, Linus Torvalds, Segher Boessenkool,
Joe Perches, Miguel Ojeda, Masahiro Yamada, Albert Ou,
Linux Kbuild mailing list, Greg Kroah-Hartman, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Palmer Dabbelt,
Paul Walmsley, Catalin Marinas, Miguel Ojeda, Paul Mackerras,
linux-riscv, linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <YJDb9uLQBgoy94Ub@ada-deb-carambola.ifak-system.com>
On Tue, May 4, 2021 at 7:31 AM Alexander Dahl <ada@thorsis.com> wrote:
> Am Mon, May 03, 2021 at 11:25:21AM +0200 schrieb Arnd Bergmann:
> > On Mon, May 3, 2021 at 9:35 AM Alexander Dahl <ada@thorsis.com> wrote:
> > >
> > > Desktops and servers are all nice, however I just want to make you
> > > aware, there are embedded users forced to stick to older cross
> > > toolchains for different reasons as well, e.g. in industrial
> > > environment. :-)
> > >
> > > This is no show stopper for us, I just wanted to let you be aware.
> >
> > Can you be more specific about what scenarios you are thinking of,
> > what the motivations are for using an old compiler with a new kernel
> > on embedded systems, and what you think a realistic maximum
> > time would be between compiler updates?
>
> One reason might be certification. For certain industrial applications
> like support for complex field bus protocols, you need to get your
> devices tested by an external partner running extensive test suites.
> This is time consuming and expensive.
>
> Changing the toolchain of your system then, would be a massive change
> which would require recertification, while you could argue just
> updating a single component like the kernel and building everything
> again, does not require the whole testing process again.
>
> Thin ice, I know.
As Christophe said, I don't think this is a valid example. I agree that
if rebuilding everything with a new toolchain requires certification, you
shouldn't rebuild everything.
If replacing the kernel does not require recertification for your
specific system, that is fine, but that does not mean the new kernel
should be built with an outdated toolchain. If the certification
allows replacing linux-3.18 with linux-5.10 but doesn't allow building
the kernel with a different toolchain compared to the rest, then
the point of the certification is rather questionable.
Do you know specific certifications that would require you to
do this?
> One problem we actually ran into in BSPs like that (we build with
> ptxdist, however build system doesn't matter here, it could as well
> have been buildroot etc.) was things* failing to build with newer
> compilers, things we could not or did not want to fix, so staying with
> an older toolchain was the obvious choice.
>
> *Things as in bootloaders for an armv5 platform.
...
>
> What we actually did: building recent userspace and kernel with older
> toolchains, because bootloader.
It sounds like you are trying to make an argument in favour of
deprecating old toolchains *earlier* in new kernels ;-)
If we simply made it impossible to have users build kernels with
the same old toolchain that is needed for building the old bootloader
or the old user space, it sounds like more people would do the
right thing and build the updated kernels with a better tested
toolchain, or update their bootloader as well. The only downside
is that some users would choose to remain on the older kernels,
so it shouldn't be too aggressive either.
Arnd
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Miguel Ojeda @ 2021-05-04 12:09 UTC (permalink / raw)
To: Michal Suchánek
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Linus Torvalds, Joe Perches, Ben Dooks, Palmer Dabbelt,
Paul Walmsley, Miguel Ojeda, Paul Mackerras, linux-riscv,
linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <20210504092225.GS6564@kitsune.suse.cz>
On Tue, May 4, 2021 at 11:22 AM Michal Suchánek <msuchanek@suse.de> wrote:
>
> Except it makes answering the question "Is this bug we see on this
> ancient system still present in upstream?" needlessly more difficult to
> answer.
Can you please provide some details? If you are talking about testing
a new kernel image in the ancient system "as-is", why wouldn't you
build it in a newer system? If you are talking about particular
problems about bisecting (kernel, compiler) pairs etc., details would
also be welcome.
> Sure, throwing out old compiler versions that are known to cause
> problems makes sense. Updating to latest just because much less so.
I definitely did not argue for "latest compiler" or "updating just because".
> One of the selling point of C in general and gcc in particular is
> stability. If we need the latest compiler we can as well rewrite the
> kernel in Rust which has a required update cycle of a few months.
Rust does not have a "required update cycle" and it does not break old
code unless really required, just like C and common compilers.
Concerning GCC, they patch releases for ~2.5 years, sure, but for many
projects that is not nearly enough. So you still need custom support,
which is anyway what most people care about.
> Because some mainline kernel features rely on bleeding edge tools I end
> up building mainline with current tools anyway but if you do not need
> BTF or whatever other latest gimmick older toolchains should do.
It would be better to hear concrete arguments about why "older
toolchains should do", rather than calling things a gimmick.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Michael Ellerman @ 2021-05-04 12:15 UTC (permalink / raw)
To: Segher Boessenkool, Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210503151824.GJ10366@gate.crashing.org>
Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Mon, May 03, 2021 at 10:51:41AM +1000, Nicholas Piggin wrote:
>> Excerpts from Segher Boessenkool's message of May 3, 2021 3:55 am:
>> > On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Segher Boessenkool's message of April 29, 2020 9:40 am:
>> >> I blame toolchain for -mabi=elfv2 ! And also some blame on ABI document
>> >> which is called ELF V2 ABI rather than ELF ABI V2 which would have been
>> >> unambiguous.
>> >
>> > At least ELFv2 ABI is correct. "ELF ABI v2" is not.
>> >
>> >> I can go through and change all my stuff and config options to ELF_ABI_v2.
>> >
>> > Please don't. It is wrong.
>>
>> Then I'm not sure what the point of your previous mail was, what did I
>> miss?
>
> I asked if you could make it clearer to people who do not know what this
> is whether they want to use it. Or that was my intention, anyhow :-/
>
>> > Both the original PowerPC ELF ABI and the
>> > ELFv2 one have versions themselves. Also, the base ELF standard has a
>> > version, and is set up so there can be incompatible versions even! Of
>> > course it still is version 1 to this day, but :-)
>>
>> The point was for people who don't know ELFv2 has a specific meaning for
>> powerpc,
>
> It does not have *any* meaning outside of Power. But people who do not
> know what it is can assume the wrong things about it. It isn't a great
> name because of that :-(
>
> (It's not as bad as the MIPS ABIs -- an older one is called "new" :-) )
>
>> then ELF ABIv2 is more explanatory about it being an abi change
>> rather than base elf change, even if it's not the "correct" name.
>
> I very much disagree. "ELF ABIv2" is completely meaningless.
Except:
$ readelf -h /bin/true
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: PowerPC64
Version: 0x1
Entry point address: 0x1990
Start of program headers: 64 (bytes into file)
Start of section headers: 66176 (bytes into file)
Flags: 0x2, abiv2
^^^^^
:)
cheers
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Michal Suchánek @ 2021-05-04 12:17 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Linus Torvalds, Joe Perches, Ben Dooks, Palmer Dabbelt,
Paul Walmsley, Miguel Ojeda, Paul Mackerras, linux-riscv,
linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <CANiq72kHwAeQ+vhFqg9tiQA-QHEK_xvP_Sro-_c5LJ2XDzjzxQ@mail.gmail.com>
On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 11:22 AM Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > Except it makes answering the question "Is this bug we see on this
> > ancient system still present in upstream?" needlessly more difficult to
> > answer.
>
> Can you please provide some details? If you are talking about testing
> a new kernel image in the ancient system "as-is", why wouldn't you
> build it in a newer system? If you are talking about particular
> problems about bisecting (kernel, compiler) pairs etc., details would
> also be welcome.
Yes, bisecting comes to mind. If you need to switch the userspace as
well the bisection results are not that solid. You may not be even able
to bisect because the workload does not exist on a new system at all.
Crafting a minimal test case that can be forward-ported to a new system
is not always trivial - if you understood the problem to that extent you
might not even need to bisect it in the first place.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Christophe Leroy @ 2021-05-04 12:26 UTC (permalink / raw)
To: Michal Suchánek, Miguel Ojeda
Cc: Albert Ou, Arnd Bergmann, Linux Kbuild mailing list,
Catalin Marinas, Masahiro Yamada, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Miguel Ojeda, Will Deacon,
Ben Dooks, Palmer Dabbelt, Paul Walmsley, Greg Kroah-Hartman,
Joe Perches, Paul Mackerras, linux-riscv, linuxppc-dev,
Linus Torvalds, Linux ARM
In-Reply-To: <20210504121713.GT6564@kitsune.suse.cz>
Le 04/05/2021 à 14:17, Michal Suchánek a écrit :
> On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:
>> On Tue, May 4, 2021 at 11:22 AM Michal Suchánek <msuchanek@suse.de> wrote:
>>>
>>> Except it makes answering the question "Is this bug we see on this
>>> ancient system still present in upstream?" needlessly more difficult to
>>> answer.
>>
>> Can you please provide some details? If you are talking about testing
>> a new kernel image in the ancient system "as-is", why wouldn't you
>> build it in a newer system? If you are talking about particular
>> problems about bisecting (kernel, compiler) pairs etc., details would
>> also be welcome.
>
> Yes, bisecting comes to mind. If you need to switch the userspace as
> well the bisection results are not that solid. You may not be even able
> to bisect because the workload does not exist on a new system at all.
> Crafting a minimal test case that can be forward-ported to a new system
> is not always trivial - if you understood the problem to that extent you
> might not even need to bisect it in the first place.
>
But you don't need to switch the userspace or the complete build tools to build a kernel with a
newer toolchain.
All you have to do is take one from https://mirrors.edge.kernel.org/pub/tools/crosstool/
I'm doing everything under CentOS 6, and using one of those tools allows me to build latest kernel
without breaking anything else.
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Greg Kurz @ 2021-05-04 12:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Daniel Vetter, kvm, David Airlie, linux-kernel, dri-devel,
qemu-devel, Alex Williamson, Paul Mackerras, Jason Gunthorpe,
Greg Kroah-Hartman, qemu-ppc, linux-api, linuxppc-dev
In-Reply-To: <20210326061311.1497642-1-hch@lst.de>
On Fri, 26 Mar 2021 07:13:09 +0100
Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> feature without any open source component - what would normally be
> the normal open source userspace that we require for kernel drivers,
> although in this particular case user space could of course be a
> kernel driver in a VM. It also happens to be a complete mess that
> does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> and also pulles in over 1000 lines of code always build into powerpc
> kernels that have Power NV support enabled. Because of all these
> issues and the lack of breaking userspace when it is removed I think
> the best idea is to simply kill.
>
> Changes since v1:
> - document the removed subtypes as reserved
> - add the ACK from Greg
>
> Diffstat:
> arch/powerpc/platforms/powernv/npu-dma.c | 705 ---------------------------
> b/arch/powerpc/include/asm/opal.h | 3
> b/arch/powerpc/include/asm/pci-bridge.h | 1
> b/arch/powerpc/include/asm/pci.h | 7
> b/arch/powerpc/platforms/powernv/Makefile | 2
> b/arch/powerpc/platforms/powernv/opal-call.c | 2
> b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 -------
> b/arch/powerpc/platforms/powernv/pci.c | 11
> b/arch/powerpc/platforms/powernv/pci.h | 17
> b/arch/powerpc/platforms/pseries/pci.c | 23
> b/drivers/vfio/pci/Kconfig | 6
> b/drivers/vfio/pci/Makefile | 1
> b/drivers/vfio/pci/vfio_pci.c | 18
> b/drivers/vfio/pci/vfio_pci_private.h | 14
> b/include/uapi/linux/vfio.h | 38 -
Hi Christoph,
FYI, these uapi changes break build of QEMU.
I guess QEMU people should take some action before this percolates
to the QEMU source tree.
Cc'ing relevant QEMU lists to bring the discussion there.
Cheers,
--
Greg
> drivers/vfio/pci/vfio_pci_nvlink2.c | 490 ------------------
> 16 files changed, 12 insertions(+), 1511 deletions(-)
^ 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