* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-26 17:01 UTC (permalink / raw)
To: Helge Deller
Cc: Michael Ellerman, Michal Hocko, linux, catalin.marinas,
will.deacon, tony.luck, fenghua.yu, ralf, paul.burton, jhogan,
jejb, benh, paulus, ysato, dalias, davem, tglx, mingo, hpa, x86,
arnd, linux-arm-kernel, linux-kernel, linux-ia64, linux-mips,
linux-parisc, linuxppc-dev, linux-sh, sparclinux, linux-arch,
Naoya Horiguchi, Mike Kravetz
In-Reply-To: <20180726125940.GA15033@ls3530>
Hi Helge,
Thanks for your tests.
In case it can help you, this is what I get when I try to build
generic-64bit_defconfig (I truncated the output):
...
LD vmlinux.o
MODPOST vmlinux.o
hppa64-linux-ld: init/main.o(.text+0x98): cannot reach strreplace
init/main.o: In function `initcall_blacklisted':
init/.tmp_main.o:(.text+0x98): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strreplace' defined in .text section
in lib/string.o
hppa64-linux-ld: init/main.o(.text+0xbc): cannot reach strcmp
init/.tmp_main.o:(.text+0xbc): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strcmp' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.text+0x21c): cannot reach strcpy
init/main.o: In function `do_one_initcall':
(.text+0x21c): relocation truncated to fit: R_PARISC_PCREL22F against
symbol `strcpy' defined in .text section in lib/string.o
hppa64-linux-ld: init/main.o(.text+0x250): cannot reach strlcat
(.text+0x250): relocation truncated to fit: R_PARISC_PCREL22F against
symbol `strlcat' defined in .text section in lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x1d4): cannot reach strcmp
init/main.o: In function `do_early_param':
init/.tmp_main.o:(.init.text+0x1d4): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strcmp' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x250): cannot reach strcmp
init/.tmp_main.o:(.init.text+0x250): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strcmp' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x294): cannot reach strlen
init/main.o: In function `repair_env_string':
init/.tmp_main.o:(.init.text+0x294): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strlen' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x2f0): cannot reach strlen
init/.tmp_main.o:(.init.text+0x2f0): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strlen' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x308): cannot reach memmove
init/.tmp_main.o:(.init.text+0x308): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `memmove' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x454): cannot reach strlen
init/main.o: In function `unknown_bootoption':
init/.tmp_main.o:(.init.text+0x454): relocation truncated to fit:
R_PARISC_PCREL22F against symbol `strlen' defined in .text section in
lib/string.o
hppa64-linux-ld: init/main.o(.init.text+0x4dc): cannot reach strchr
init/.tmp_main.o:(.init.text+0x4dc): additional relocation overflows
omitted from the output
hppa64-linux-ld: init/main.o(.init.text+0x638): cannot reach strncmp
hppa64-linux-ld: init/main.o(.init.text+0x694): cannot reach get_option
hppa64-linux-ld: init/main.o(.init.text+0x744): cannot reach strsep
hppa64-linux-ld: init/main.o(.init.text+0x798): cannot reach strlen
hppa64-linux-ld: init/main.o(.init.text+0x7d0): cannot reach strcpy
hppa64-linux-ld: init/main.o(.init.text+0x954): cannot reach strlcpy
hppa64-linux-ld: init/main.o(.init.text+0xab8): cannot reach strlen
hppa64-linux-ld: init/main.o(.init.text+0xafc): cannot reach strlen
hppa64-linux-ld: init/main.o(.init.text+0xb40): cannot reach strlen
hppa64-linux-ld: init/main.o(.init.text+0xb84): cannot reach strlen
hppa64-linux-ld: init/main.o(.init.text+0xbd0): cannot reach strcpy
hppa64-linux-ld: init/main.o(.init.text+0xbe8): cannot reach strcpy
hppa64-linux-ld: init/main.o(.init.text+0xc3c): cannot reach
build_all_zonelists
hppa64-linux-ld: init/main.o(.init.text+0x1200): cannot reach unknown
hppa64-linux-ld: init/main.o(.init.text+0x1278): cannot reach
wait_for_completion
hppa64-linux-ld: init/main.o(.init.text+0x12b0): cannot reach _raw_spin_lock
hppa64-linux-ld: init/main.o(.init.text+0x147c): cannot reach strcpy
hppa64-linux-ld: init/main.o(.ref.text+0x40): cannot reach kernel_thread
hppa64-linux-ld: init/main.o(.ref.text+0x60): cannot reach
find_task_by_pid_ns
hppa64-linux-ld: init/main.o(.ref.text+0x98): cannot reach
set_cpus_allowed_ptr
hppa64-linux-ld: init/main.o(.ref.text+0xbc): cannot reach kernel_thread
hppa64-linux-ld: init/main.o(.ref.text+0xd4): cannot reach
find_task_by_pid_ns
hppa64-linux-ld: init/main.o(.ref.text+0x108): cannot reach complete
hppa64-linux-ld: init/main.o(.ref.text+0x128): cannot reach
cpu_startup_entry
hppa64-linux-ld: init/main.o(.ref.text+0x164): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x174): cannot reach
async_synchronize_full
hppa64-linux-ld: init/main.o(.ref.text+0x1a4): cannot reach
rcu_barrier_sched
hppa64-linux-ld: init/main.o(.ref.text+0x1b4): cannot reach mark_rodata_ro
hppa64-linux-ld: init/main.o(.ref.text+0x1d4): cannot reach
rcu_end_inkernel_boot
hppa64-linux-ld: init/main.o(.ref.text+0x1f4): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x218): cannot reach printk
hppa64-linux-ld: init/main.o(.ref.text+0x238): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x258): cannot reach panic
hppa64-linux-ld: init/main.o(.ref.text+0x268): cannot reach printk
hppa64-linux-ld: init/main.o(.ref.text+0x280): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x29c): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x2b8): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x2d4): cannot reach unknown
hppa64-linux-ld: init/main.o(.ref.text+0x2f0): cannot reach panic
hppa64-linux-ld: init/do_mounts.o(.text+0x30): cannot reach strncasecmp
hppa64-linux-ld: init/do_mounts.o(.text+0x158): cannot reach strncmp
hppa64-linux-ld: init/do_mounts.o(.text+0x180): cannot reach strchr
...
On 07/26/2018 12:59 PM, Helge Deller wrote:
> * Alex Ghiti <alex@ghiti.fr>:
>> This is the result of the build for all arches tackled in this series
>> rebased on 4.18-rc6:
>> ...
>> parisc:
>> generic-64bit_defconfig: with huge page does not link
>> generic-64bit_defconfig: without huge page does not link
>> BUT not because of this series, any feedback welcome.
> Strange, but I will check that later....
>
> Anyway, I applied your v4-patch to my parisc64 tree, built the kernel,
> started it and ran some hugetlb LTP testcases sucessfully.
> So, please add:
>
> Tested-by: Helge Deller <deller@gmx.de> # parisc
>
> Helge
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-26 16:46 UTC (permalink / raw)
To: LEROY Christophe
Cc: Mike Kravetz, davem, linuxppc-dev, Naoya Horiguchi, paul.burton,
ralf, linux-kernel, linux-parisc, tony.luck, linux-arm-kernel,
tglx, arnd, fenghua.yu, jhogan, catalin.marinas, mingo, linux,
x86, deller, ysato, linux-arch, sparclinux, hpa, paulus, jejb,
will.deacon, linux-sh, linux-ia64, dalias, linux-mips,
Michal Hocko, Michael Ellerman
In-Reply-To: <20180726171355.Horde.KlFUG9wXmbRDCiyhk5bHsw8@messagerie.si.c-s.fr>
Hi Christophe,
Sorry, I should have done it already: with and without huge page
activated, the build for mpc885_ads_defconfig is OK.
Thanks,
Alex
On 07/26/2018 03:13 PM, LEROY Christophe wrote:
> Alex Ghiti <alex@ghiti.fr> a écrit :
>
>> Hi everyone,
>>
>> This is the result of the build for all arches tackled in this series
>> rebased on 4.18-rc6:
>>
>> arm:
>> versatile_defconfig: without huge page OK
>> keystone_defconfig: with huge page OK
>> arm64:
>> defconfig: with huge page OK
>> ia64:
>> generic_defconfig: with huge page OK
>> mips:
>> Paul Burton tested cavium octeon with huge page OK
>> parisc:
>> generic-64bit_defconfig: with huge page does not link
>> generic-64bit_defconfig: without huge page does not link
>> BUT not because of this series, any feedback welcome.
>> powerpc:
>> ppc64_defconfig: without huge page OK
>> ppc64_defconfig: with huge page OK
>
> Can you also test ppc32 both with and without hugepage
> (mpc885_ads_defconfig)
>
> Thanks
> Christophe
>
>> sh:
>> dreamcast_defconfig: with huge page OK
>> sparc:
>> sparc32_defconfig: without huge page OK
>> sparc64:
>> sparc64_defconfig: with huge page OK
>> x86:
>> with huge page OK
>>
>> Alex
>>
>> On 07/23/2018 02:00 PM, Michael Ellerman wrote:
>>> Alex Ghiti <alex@ghiti.fr> writes:
>>>
>>>> Does anyone have any suggestion about those patches ?
>>> Cross compiling it for some non-x86 arches would be a good start :)
>>>
>>> There are cross compilers available here:
>>>
>>> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>>>
>>>
>>> cheers
>>>
>>>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>>>> [CC hugetlb guys -
>>>>> http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>>>
>>>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>>>> In order to reduce copy/paste of functions across architectures
>>>>>> and then
>>>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>>>> patchset intends to factorize the numerous hugetlb primitives
>>>>>> that are
>>>>>> defined across all the architectures.
>>>>>>
>>>>>> Except for prepare_hugepage_range, this patchset moves the
>>>>>> versions that
>>>>>> are just pass-through to standard pte primitives into
>>>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>>>
>>>>>> s390 architecture has not been tackled in this serie since it
>>>>>> does not
>>>>>> use asm-generic/hugetlb.h at all.
>>>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>>>
>>>>>> This patchset has been compiled on x86 only.
>>>>>>
>>>>>> Changelog:
>>>>>>
>>>>>> v4:
>>>>>> Fix powerpc build error due to misplacing of #include
>>>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>>>> pointed by Christophe Leroy.
>>>>>>
>>>>>> v1, v2, v3:
>>>>>> Same version, just problems with email provider and misuse of
>>>>>> --batch-size option of git send-email
>>>>>>
>>>>>> Alexandre Ghiti (11):
>>>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>>>> hugetlb: Introduce generic version of huge_pte_none
>>>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>>>
>>>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>>>> arch/sh/include/asm/hugetlb.h | 54
>>>>>> ++---------------
>>>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>>>> arch/x86/include/asm/hugetlb.h | 72
>>>>>> +----------------------
>>>>>> include/asm-generic/hugetlb.h | 88
>>>>>> +++++++++++++++++++++++++++-
>>>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>>>
>>>>>> --
>>>>>> 2.16.2
>
>
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: LEROY Christophe @ 2018-07-26 15:13 UTC (permalink / raw)
To: Alex Ghiti
Cc: Mike Kravetz, davem, linuxppc-dev, Naoya Horiguchi, paul.burton,
ralf, linux-kernel, linux-parisc, tony.luck, linux-arm-kernel,
tglx, arnd, fenghua.yu, jhogan, catalin.marinas, mingo, linux,
x86, deller, ysato, linux-arch, sparclinux, hpa, paulus, jejb,
will.deacon, linux-sh, linux-ia64, dalias, linux-mips,
Michal Hocko, Michael Ellerman
In-Reply-To: <67aba0f0-c0d4-b06f-5fbc-f4d113ce5033@ghiti.fr>
Alex Ghiti <alex@ghiti.fr> a =C3=A9crit=C2=A0:
> Hi everyone,
>
> This is the result of the build for all arches tackled in this=20=20
>=20series rebased on 4.18-rc6:
>
> arm:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 versatile_defconfig: without h=
uge page OK
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 keystone_defconfig: with huge =
page OK
> arm64:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defconfig: with huge page OK
> ia64:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generic_defconfig: with huge p=
age OK
> mips:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Paul Burton tested cavium octe=
on with huge page OK
> parisc:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generic-64bit_defconfig: with =
huge page does not link
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generic-64bit_defconfig: witho=
ut huge page does not link
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BUT not because of this series=
, any feedback welcome.
> powerpc:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ppc64_defconfig: without huge =
page OK
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ppc64_defconfig: with huge pag=
e OK
Can you also test ppc32 both with and without hugepage (mpc885_ads_defconfi=
g)
Thanks
Christophe
> sh:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dreamcast_defconfig: with huge=
page OK
> sparc:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sparc32_defconfig: without hug=
e page OK
> sparc64:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sparc64_defconfig: with huge p=
age OK
> x86:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with huge page OK
>
> Alex
>
> On 07/23/2018 02:00 PM, Michael Ellerman wrote:
>> Alex Ghiti <alex@ghiti.fr> writes:
>>
>>> Does anyone have any suggestion about those patches ?
>> Cross compiling it for some non-x86 arches would be a good start :)
>>
>> There are cross compilers available here:
>>
>> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>>
>>
>> cheers
>>
>>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>>> [CC hugetlb guys -=20=20
>>>>=20http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>>
>>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>>> In order to reduce copy/paste of functions across architectures and t=
hen
>>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>>> patchset intends to factorize the numerous hugetlb primitives that ar=
e
>>>>> defined across all the architectures.
>>>>>
>>>>> Except for prepare_hugepage_range, this patchset moves the versions t=
hat
>>>>> are just pass-through to standard pte primitives into
>>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>>
>>>>> s390 architecture has not been tackled in this serie since it does no=
t
>>>>> use asm-generic/hugetlb.h at all.
>>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>>
>>>>> This patchset has been compiled on x86 only.
>>>>>
>>>>> Changelog:
>>>>>
>>>>> v4:
>>>>> Fix powerpc build error due to misplacing of #include
>>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>>> pointed by Christophe Leroy.
>>>>>
>>>>> v1, v2, v3:
>>>>> Same version, just problems with email provider and misuse of
>>>>> --batch-size option of git send-email
>>>>>
>>>>> Alexandre Ghiti (11):
>>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>>> hugetlb: Introduce generic version of huge_pte_none
>>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>>
>>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>>> arch/x86/include/asm/hugetlb.h | 72=20=20
>>>>>=20+----------------------
>>>>> include/asm-generic/hugetlb.h | 88=20=20
>>>>>=20+++++++++++++++++++++++++++-
>>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>>
>>>>> --=20
>>>>>=202.16.2
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 15:10 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726140152.GM28386@dhcp22.suse.cz>
On 07/26/18 at 04:01pm, Michal Hocko wrote:
> On Thu 26-07-18 21:37:05, Baoquan He wrote:
> > On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > > > have this worry.
> > > > > > > >
> > > > > > > > I do not have the full context here but let me note that you should be
> > > > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > > > this is done. See memblock_find_in_range_node
> > > > > > >
> > > > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > > > detected.
> > > > > >
> > > > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > > > and do not know what to do about them. They are not migrateable.
> > > > > > Allocating intermediate pages from other nodes doesn't really help.
> > > > >
> > > > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > > > is at top of system RAM and the top RAM is in movable node.
> > > >
> > > > It will affect the 1st kernel (which does the memblock allocation
> > > > top-down) as well. For reasons mentioned above.
> > >
> > > And btw. in the ideal world, we would restrict the memblock allocation
> > > top-down from the non-movable nodes. But I do not think we have that
> > > information ready at the time when the reservation is done.
> >
> > Oh, you could mix kexec loading up with kdump kernel loading. For kdump
> > kernel, we need reserve memory region during bootup with memblock
> > allocator. For kexec loading, we just operate after system up, and do
> > not need to reserve any memmory region. About memory used to load them,
> > it's quite different way.
>
> I didn't know about that. I thought both use the same underlying
> reservation mechanism. My bad and sorry for the noise.
Not at all. It's truly confusing. I often need take time to recall those
details.
^ permalink raw reply
* Re: [PATCH kernel for v4.14 and v4.17 stable] KVM: PPC: Check if IOMMU page is contained in the pinned physical page
From: Greg KH @ 2018-07-26 15:07 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, Michael Ellerman, stable, #, v4.12+
In-Reply-To: <20180724053247.26870-1-aik@ozlabs.ru>
On Tue, Jul 24, 2018 at 03:32:47PM +1000, Alexey Kardashevskiy wrote:
> A VM which has:
> - a DMA capable device passed through to it (eg. network card);
> - running a malicious kernel that ignores H_PUT_TCE failure;
> - capability of using IOMMU pages bigger that physical pages
> can create an IOMMU mapping that exposes (for example) 16MB of
> the host physical memory to the device when only 64K was allocated to the VM.
>
> The remaining 16MB - 64K will be some other content of host memory, possibly
> including pages of the VM, but also pages of host kernel memory, host
> programs or other VMs.
>
> The attacking VM does not control the location of the page it can map,
> and is only allowed to map as many pages as it has pages of RAM.
>
> We already have a check in drivers/vfio/vfio_iommu_spapr_tce.c that
> an IOMMU page is contained in the physical page so the PCI hardware won't
> get access to unassigned host memory; however this check is missing in
> the KVM fastpath (H_PUT_TCE accelerated code). We were lucky so far and
> did not hit this yet as the very first time when the mapping happens
> we do not have tbl::it_userspace allocated yet and fall back to
> the userspace which in turn calls VFIO IOMMU driver, this fails and
> the guest does not retry,
>
> This stores the smallest preregistered page size in the preregistered
> region descriptor and changes the mm_iommu_xxx API to check this against
> the IOMMU page size.
>
> This calculates maximum page size as a minimum of the natural region
> alignment and compound page size. For the page shift this uses the shift
> returned by find_linux_pte() which indicates how the page is mapped to
> the current userspace - if the page is huge and this is not a zero, then
> it is a leaf pte and the page is mapped within the range.
>
> Fixes: 121f80ba68f1 ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
> Cc: stable@vger.kernel.org # v4.12+
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> (cherry picked from commit 76fa4975f3ed12d15762bc979ca44078598ed8ee)
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> The original patch did not apply because of fad953ce which fixed
> all vmalloc's to use array_size() so the backport is pretty trivial
> and applies to v4.17 stable as well.
THanks for the backport, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 14:01 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726133705.GM6480@MiWiFi-R3L-srv>
On Thu 26-07-18 21:37:05, Baoquan He wrote:
> On 07/26/18 at 03:14pm, Michal Hocko wrote:
> > On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > > have this worry.
> > > > > > >
> > > > > > > I do not have the full context here but let me note that you should be
> > > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > > this is done. See memblock_find_in_range_node
> > > > > >
> > > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > > detected.
> > > > >
> > > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > > and do not know what to do about them. They are not migrateable.
> > > > > Allocating intermediate pages from other nodes doesn't really help.
> > > >
> > > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > > is at top of system RAM and the top RAM is in movable node.
> > >
> > > It will affect the 1st kernel (which does the memblock allocation
> > > top-down) as well. For reasons mentioned above.
> >
> > And btw. in the ideal world, we would restrict the memblock allocation
> > top-down from the non-movable nodes. But I do not think we have that
> > information ready at the time when the reservation is done.
>
> Oh, you could mix kexec loading up with kdump kernel loading. For kdump
> kernel, we need reserve memory region during bootup with memblock
> allocator. For kexec loading, we just operate after system up, and do
> not need to reserve any memmory region. About memory used to load them,
> it's quite different way.
I didn't know about that. I thought both use the same underlying
reservation mechanism. My bad and sorry for the noise.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 13:37 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726131420.GJ28386@dhcp22.suse.cz>
On 07/26/18 at 03:14pm, Michal Hocko wrote:
> On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> > On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > > have this worry.
> > > > > >
> > > > > > I do not have the full context here but let me note that you should be
> > > > > > careful when doing top-down reservation because you can easily get into
> > > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > > this is done. See memblock_find_in_range_node
> > > > >
> > > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > > the @buf stores the user space buffer address, @mem stores the position
> > > > > where kernel/initrd will be put. In kernel, it calls
> > > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > > @mem we searched in the whole system RAM might be lost along with
> > > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > > detected.
> > > >
> > > > I am not sure I am following. If @mem is placed at movable node then the
> > > > memory hotremove simply won't work, because we are seeing reserved pages
> > > > and do not know what to do about them. They are not migrateable.
> > > > Allocating intermediate pages from other nodes doesn't really help.
> > >
> > > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > > is at top of system RAM and the top RAM is in movable node.
> >
> > It will affect the 1st kernel (which does the memblock allocation
> > top-down) as well. For reasons mentioned above.
>
> And btw. in the ideal world, we would restrict the memblock allocation
> top-down from the non-movable nodes. But I do not think we have that
> information ready at the time when the reservation is done.
Oh, you could mix kexec loading up with kdump kernel loading. For kdump
kernel, we need reserve memory region during bootup with memblock
allocator. For kexec loading, we just operate after system up, and do
not need to reserve any memmory region. About memory used to load them,
it's quite different way.
Thanks
Baoquan
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 13:14 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726131242.GI28386@dhcp22.suse.cz>
On Thu 26-07-18 15:12:42, Michal Hocko wrote:
> On Thu 26-07-18 21:09:04, Baoquan He wrote:
> > On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > > those kind of very large machine can make use of this feature to speed
> > > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > > it. It may have possibility to not be able to find a usable space for
> > > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > > have this worry.
> > > > >
> > > > > I do not have the full context here but let me note that you should be
> > > > > careful when doing top-down reservation because you can easily get into
> > > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > > this is done. See memblock_find_in_range_node
> > > >
> > > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > > for them to do the later copying. You can see below struct kexec_segment,
> > > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > > the @buf stores the user space buffer address, @mem stores the position
> > > > where kernel/initrd will be put. In kernel, it calls
> > > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > > kexec jumping, it will do the final copying from the intermediate pages
> > > > to the real destination pages which @mem pointed. Because we can't touch
> > > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > > understanding, GFP_KERNEL will make those intermediate pages be
> > > > allocated inside immovable area, it won't impact hotplugging. But the
> > > > @mem we searched in the whole system RAM might be lost along with
> > > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > > detected.
> > >
> > > I am not sure I am following. If @mem is placed at movable node then the
> > > memory hotremove simply won't work, because we are seeing reserved pages
> > > and do not know what to do about them. They are not migrateable.
> > > Allocating intermediate pages from other nodes doesn't really help.
> >
> > OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> > in 1st kernel, it does impact the kernel which kexec jump into if kernel
> > is at top of system RAM and the top RAM is in movable node.
>
> It will affect the 1st kernel (which does the memblock allocation
> top-down) as well. For reasons mentioned above.
And btw. in the ideal world, we would restrict the memblock allocation
top-down from the non-movable nodes. But I do not think we have that
information ready at the time when the reservation is done.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Michal Hocko @ 2018-07-26 13:12 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726130904.GL6480@MiWiFi-R3L-srv>
On Thu 26-07-18 21:09:04, Baoquan He wrote:
> On 07/26/18 at 02:59pm, Michal Hocko wrote:
> > On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > > Kexec has been a formal feature in our distro, and customers owning
> > > > > those kind of very large machine can make use of this feature to speed
> > > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > > search place to put kernel under 4G from top to down. As we know, the
> > > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > > it. It may have possibility to not be able to find a usable space for
> > > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > > have this worry.
> > > >
> > > > I do not have the full context here but let me note that you should be
> > > > careful when doing top-down reservation because you can easily get into
> > > > hotplugable memory and break the hotremove usecase. We even warn when
> > > > this is done. See memblock_find_in_range_node
> > >
> > > Kexec read kernel/initrd file into buffer, just search usable positions
> > > for them to do the later copying. You can see below struct kexec_segment,
> > > for the old kexec_load, kernel/initrd are read into user space buffer,
> > > the @buf stores the user space buffer address, @mem stores the position
> > > where kernel/initrd will be put. In kernel, it calls
> > > kimage_load_normal_segment() to copy user space buffer to intermediate
> > > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > > are recorded as entries, later when user execute "kexec -e" to trigger
> > > kexec jumping, it will do the final copying from the intermediate pages
> > > to the real destination pages which @mem pointed. Because we can't touch
> > > the existed data in 1st kernel when do kexec kernel loading. With my
> > > understanding, GFP_KERNEL will make those intermediate pages be
> > > allocated inside immovable area, it won't impact hotplugging. But the
> > > @mem we searched in the whole system RAM might be lost along with
> > > hotplug. Hence we need do kexec kernel again when hotplug event is
> > > detected.
> >
> > I am not sure I am following. If @mem is placed at movable node then the
> > memory hotremove simply won't work, because we are seeing reserved pages
> > and do not know what to do about them. They are not migrateable.
> > Allocating intermediate pages from other nodes doesn't really help.
>
> OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
> in 1st kernel, it does impact the kernel which kexec jump into if kernel
> is at top of system RAM and the top RAM is in movable node.
It will affect the 1st kernel (which does the memblock allocation
top-down) as well. For reasons mentioned above.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required
From: Baoquan He @ 2018-07-26 13:09 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, linux-kernel, robh+dt, dan.j.williams,
nicolas.pitre, josh, fengguang.wu, bp, andy.shevchenko,
patrik.r.jakobsson, airlied, kys, haiyangz, sthemmin,
dmitry.torokhov, frowand.list, keith.busch, jonathan.derrick,
lorenzo.pieralisi, bhelgaas, tglx, brijesh.singh, jglisse,
thomas.lendacky, gregkh, baiyaowei, richard.weiyang, devel,
linux-input, linux-nvdimm, devicetree, linux-pci, ebiederm,
vgoyal, dyoung, yinghai, monstr, davem, chris, jcmvbkbc, gustavo,
maarten.lankhorst, seanpaul, linux-parisc, linuxppc-dev, kexec
In-Reply-To: <20180726125957.GH28386@dhcp22.suse.cz>
On 07/26/18 at 02:59pm, Michal Hocko wrote:
> On Wed 25-07-18 14:48:13, Baoquan He wrote:
> > On 07/23/18 at 04:34pm, Michal Hocko wrote:
> > > On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > > > Kexec has been a formal feature in our distro, and customers owning
> > > > those kind of very large machine can make use of this feature to speed
> > > > up the reboot process. On uefi machine, the kexec_file loading will
> > > > search place to put kernel under 4G from top to down. As we know, the
> > > > 1st 4G space is DMA32 ZONE, dma, pci mmcfg, bios etc all try to consume
> > > > it. It may have possibility to not be able to find a usable space for
> > > > kernel/initrd. From the top down of the whole memory space, we don't
> > > > have this worry.
> > >
> > > I do not have the full context here but let me note that you should be
> > > careful when doing top-down reservation because you can easily get into
> > > hotplugable memory and break the hotremove usecase. We even warn when
> > > this is done. See memblock_find_in_range_node
> >
> > Kexec read kernel/initrd file into buffer, just search usable positions
> > for them to do the later copying. You can see below struct kexec_segment,
> > for the old kexec_load, kernel/initrd are read into user space buffer,
> > the @buf stores the user space buffer address, @mem stores the position
> > where kernel/initrd will be put. In kernel, it calls
> > kimage_load_normal_segment() to copy user space buffer to intermediate
> > pages which are allocated with flag GFP_KERNEL. These intermediate pages
> > are recorded as entries, later when user execute "kexec -e" to trigger
> > kexec jumping, it will do the final copying from the intermediate pages
> > to the real destination pages which @mem pointed. Because we can't touch
> > the existed data in 1st kernel when do kexec kernel loading. With my
> > understanding, GFP_KERNEL will make those intermediate pages be
> > allocated inside immovable area, it won't impact hotplugging. But the
> > @mem we searched in the whole system RAM might be lost along with
> > hotplug. Hence we need do kexec kernel again when hotplug event is
> > detected.
>
> I am not sure I am following. If @mem is placed at movable node then the
> memory hotremove simply won't work, because we are seeing reserved pages
> and do not know what to do about them. They are not migrateable.
> Allocating intermediate pages from other nodes doesn't really help.
OK, I forgot the 2nd kernel which kexec jump into. It won't impact hotremove
in 1st kernel, it does impact the kernel which kexec jump into if kernel
is at top of system RAM and the top RAM is in movable node.
>
> The memblock code warns exactly for that reason.
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* [PATCH 16/16] powerpc/64s: Don't use __MASKABLE_EXCEPTION unnecessarily
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
We only need to use __MASKABLE_EXCEPTION in one of the four cases for
hardware interrupt, so use the helper macros in the other cases.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/exceptions-64s.S | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 54abb72a5ae1..8e1396433eb4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -770,13 +770,9 @@ EXC_REAL_BEGIN(hardware_interrupt, 0x500, 0x100)
.globl hardware_interrupt_hv;
hardware_interrupt_hv:
BEGIN_FTR_SECTION
- __MASKABLE_EXCEPTION(0x500, hardware_interrupt_common,
- EXC_HV, SOFTEN_TEST_HV,
- IRQS_DISABLED)
+ MASKABLE_EXCEPTION_HV(0x500, hardware_interrupt_common, IRQS_DISABLED)
FTR_SECTION_ELSE
- __MASKABLE_EXCEPTION(0x500, hardware_interrupt_common,
- EXC_STD, SOFTEN_TEST_PR,
- IRQS_DISABLED)
+ MASKABLE_EXCEPTION(0x500, hardware_interrupt_common, IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
EXC_REAL_END(hardware_interrupt, 0x500, 0x100)
@@ -784,13 +780,11 @@ EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x100)
.globl hardware_interrupt_relon_hv;
hardware_interrupt_relon_hv:
BEGIN_FTR_SECTION
- __MASKABLE_RELON_EXCEPTION(0x500, hardware_interrupt_common,
- EXC_HV, SOFTEN_TEST_HV,
- IRQS_DISABLED)
+ MASKABLE_RELON_EXCEPTION_HV(0x500, hardware_interrupt_common,
+ IRQS_DISABLED)
FTR_SECTION_ELSE
__MASKABLE_RELON_EXCEPTION(0x500, hardware_interrupt_common,
- EXC_STD, SOFTEN_TEST_PR,
- IRQS_DISABLED)
+ EXC_STD, SOFTEN_TEST_PR, IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
EXC_VIRT_END(hardware_interrupt, 0x4500, 0x100)
--
2.14.1
^ permalink raw reply related
* [PATCH 15/16] powerpc/64s: Drop unused loc parameter to MASKABLE_EXCEPTION macros
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
We pass the "loc" (location) parameter to MASKABLE_EXCEPTION and
friends, but it's not used, so drop it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 8 ++++----
arch/powerpc/include/asm/head-64.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 75af99251501..d010bdb5fcbe 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -628,14 +628,14 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2(label, h);
-#define MASKABLE_EXCEPTION(loc, vec, label, bitmask) \
+#define MASKABLE_EXCEPTION(vec, label, bitmask) \
__MASKABLE_EXCEPTION(vec, label, EXC_STD, SOFTEN_TEST_PR, bitmask)
#define MASKABLE_EXCEPTION_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD)
-#define MASKABLE_EXCEPTION_HV(loc, vec, label, bitmask) \
+#define MASKABLE_EXCEPTION_HV(vec, label, bitmask) \
__MASKABLE_EXCEPTION(vec, label, EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_EXCEPTION_HV_OOL(vec, label, bitmask) \
@@ -648,14 +648,14 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2_RELON(label, h)
-#define MASKABLE_RELON_EXCEPTION(loc, vec, label, bitmask) \
+#define MASKABLE_RELON_EXCEPTION(vec, label, bitmask) \
__MASKABLE_RELON_EXCEPTION(vec, label, EXC_STD, SOFTEN_NOTEST_PR, bitmask)
#define MASKABLE_RELON_EXCEPTION_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_NOTEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD);
-#define MASKABLE_RELON_EXCEPTION_HV(loc, vec, label, bitmask) \
+#define MASKABLE_RELON_EXCEPTION_HV(vec, label, bitmask) \
__MASKABLE_RELON_EXCEPTION(vec, label, EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_RELON_EXCEPTION_HV_OOL(vec, label, bitmask) \
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index 5678f82cf355..a4f947888744 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -270,12 +270,12 @@ end_##sname:
#define EXC_REAL_MASKABLE(name, start, size, bitmask) \
EXC_REAL_BEGIN(name, start, size); \
- MASKABLE_EXCEPTION(start, start, name##_common, bitmask); \
+ MASKABLE_EXCEPTION(start, name##_common, bitmask); \
EXC_REAL_END(name, start, size);
#define EXC_VIRT_MASKABLE(name, start, size, realvec, bitmask) \
EXC_VIRT_BEGIN(name, start, size); \
- MASKABLE_RELON_EXCEPTION(start, realvec, name##_common, bitmask);\
+ MASKABLE_RELON_EXCEPTION(realvec, name##_common, bitmask); \
EXC_VIRT_END(name, start, size);
#define EXC_REAL_HV(name, start, size) \
--
2.14.1
^ permalink raw reply related
* [PATCH 14/16] powerpc/64s: Remove PSERIES naming from the MASKABLE macros
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 24 ++++++++++--------------
arch/powerpc/include/asm/head-64.h | 8 ++++----
arch/powerpc/kernel/exceptions-64s.S | 8 ++++----
3 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 020f78995a3d..75af99251501 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -622,45 +622,41 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define SOFTEN_NOTEST_PR(vec, bitmask) _SOFTEN_TEST(EXC_STD, vec, bitmask)
#define SOFTEN_NOTEST_HV(vec, bitmask) _SOFTEN_TEST(EXC_HV, vec, bitmask)
-#define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra, bitmask) \
+#define __MASKABLE_EXCEPTION(vec, label, h, extra, bitmask) \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2(label, h);
-#define MASKABLE_EXCEPTION_PSERIES(loc, vec, label, bitmask) \
- __MASKABLE_EXCEPTION_PSERIES(vec, label, \
- EXC_STD, SOFTEN_TEST_PR, bitmask)
+#define MASKABLE_EXCEPTION(loc, vec, label, bitmask) \
+ __MASKABLE_EXCEPTION(vec, label, EXC_STD, SOFTEN_TEST_PR, bitmask)
-#define MASKABLE_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
+#define MASKABLE_EXCEPTION_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD)
#define MASKABLE_EXCEPTION_HV(loc, vec, label, bitmask) \
- __MASKABLE_EXCEPTION_PSERIES(vec, label, \
- EXC_HV, SOFTEN_TEST_HV, bitmask)
+ __MASKABLE_EXCEPTION(vec, label, EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_HV)
-#define __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask) \
+#define __MASKABLE_RELON_EXCEPTION(vec, label, h, extra, bitmask) \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2_RELON(label, h)
-#define MASKABLE_RELON_EXCEPTION_PSERIES(loc, vec, label, bitmask) \
- __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
- EXC_STD, SOFTEN_NOTEST_PR, bitmask)
+#define MASKABLE_RELON_EXCEPTION(loc, vec, label, bitmask) \
+ __MASKABLE_RELON_EXCEPTION(vec, label, EXC_STD, SOFTEN_NOTEST_PR, bitmask)
-#define MASKABLE_RELON_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
+#define MASKABLE_RELON_EXCEPTION_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_NOTEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD);
#define MASKABLE_RELON_EXCEPTION_HV(loc, vec, label, bitmask) \
- __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
- EXC_HV, SOFTEN_TEST_HV, bitmask)
+ __MASKABLE_RELON_EXCEPTION(vec, label, EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_RELON_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index 640d354a3ab3..5678f82cf355 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -270,12 +270,12 @@ end_##sname:
#define EXC_REAL_MASKABLE(name, start, size, bitmask) \
EXC_REAL_BEGIN(name, start, size); \
- MASKABLE_EXCEPTION_PSERIES(start, start, name##_common, bitmask);\
+ MASKABLE_EXCEPTION(start, start, name##_common, bitmask); \
EXC_REAL_END(name, start, size);
#define EXC_VIRT_MASKABLE(name, start, size, realvec, bitmask) \
EXC_VIRT_BEGIN(name, start, size); \
- MASKABLE_RELON_EXCEPTION_PSERIES(start, realvec, name##_common, bitmask);\
+ MASKABLE_RELON_EXCEPTION(start, realvec, name##_common, bitmask);\
EXC_VIRT_END(name, start, size);
#define EXC_REAL_HV(name, start, size) \
@@ -306,7 +306,7 @@ end_##sname:
#define __TRAMP_REAL_OOL_MASKABLE(name, vec, bitmask) \
TRAMP_REAL_BEGIN(tramp_real_##name); \
- MASKABLE_EXCEPTION_PSERIES_OOL(vec, name##_common, bitmask); \
+ MASKABLE_EXCEPTION_OOL(vec, name##_common, bitmask);
#define EXC_REAL_OOL_MASKABLE(name, start, size, bitmask) \
__EXC_REAL_OOL_MASKABLE(name, start, size); \
@@ -357,7 +357,7 @@ end_##sname:
#define __TRAMP_VIRT_OOL_MASKABLE(name, realvec, bitmask) \
TRAMP_VIRT_BEGIN(tramp_virt_##name); \
- MASKABLE_RELON_EXCEPTION_PSERIES_OOL(realvec, name##_common, bitmask);\
+ MASKABLE_RELON_EXCEPTION_OOL(realvec, name##_common, bitmask);
#define EXC_VIRT_OOL_MASKABLE(name, start, size, realvec, bitmask) \
__EXC_VIRT_OOL_MASKABLE(name, start, size); \
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 0787814e309b..54abb72a5ae1 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -770,11 +770,11 @@ EXC_REAL_BEGIN(hardware_interrupt, 0x500, 0x100)
.globl hardware_interrupt_hv;
hardware_interrupt_hv:
BEGIN_FTR_SECTION
- __MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_EXCEPTION(0x500, hardware_interrupt_common,
EXC_HV, SOFTEN_TEST_HV,
IRQS_DISABLED)
FTR_SECTION_ELSE
- __MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_EXCEPTION(0x500, hardware_interrupt_common,
EXC_STD, SOFTEN_TEST_PR,
IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
@@ -784,11 +784,11 @@ EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x100)
.globl hardware_interrupt_relon_hv;
hardware_interrupt_relon_hv:
BEGIN_FTR_SECTION
- __MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_RELON_EXCEPTION(0x500, hardware_interrupt_common,
EXC_HV, SOFTEN_TEST_HV,
IRQS_DISABLED)
FTR_SECTION_ELSE
- __MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_RELON_EXCEPTION(0x500, hardware_interrupt_common,
EXC_STD, SOFTEN_TEST_PR,
IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
--
2.14.1
^ permalink raw reply related
* [PATCH 13/16] powerpc/64s: Drop _MASKABLE_RELON_EXCEPTION_PSERIES()
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
_MASKABLE_RELON_EXCEPTION_PSERIES() does nothing useful, update all
callers to use __MASKABLE_RELON_EXCEPTION_PSERIES() directly.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 11 ++++-------
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 70c3810c6476..020f78995a3d 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -650,20 +650,17 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2_RELON(label, h)
-#define _MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)\
- __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)
-
#define MASKABLE_RELON_EXCEPTION_PSERIES(loc, vec, label, bitmask) \
- _MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
- EXC_STD, SOFTEN_NOTEST_PR, bitmask)
+ __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
+ EXC_STD, SOFTEN_NOTEST_PR, bitmask)
#define MASKABLE_RELON_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_NOTEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD);
#define MASKABLE_RELON_EXCEPTION_HV(loc, vec, label, bitmask) \
- _MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
- EXC_HV, SOFTEN_TEST_HV, bitmask)
+ __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
+ EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_RELON_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 67be3e72c7d1..0787814e309b 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -784,11 +784,11 @@ EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x100)
.globl hardware_interrupt_relon_hv;
hardware_interrupt_relon_hv:
BEGIN_FTR_SECTION
- _MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
EXC_HV, SOFTEN_TEST_HV,
IRQS_DISABLED)
FTR_SECTION_ELSE
- _MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
EXC_STD, SOFTEN_TEST_PR,
IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
--
2.14.1
^ permalink raw reply related
* [PATCH 12/16] powerpc/64s: Drop _MASKABLE_EXCEPTION_PSERIES()
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
_MASKABLE_EXCEPTION_PSERIES() does nothing useful, update all callers
to use __MASKABLE_EXCEPTION_PSERIES() directly.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 11 ++++-------
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 728532c5f585..70c3810c6476 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -628,20 +628,17 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
EXCEPTION_PROLOG_2(label, h);
-#define _MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra, bitmask) \
- __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)
-
#define MASKABLE_EXCEPTION_PSERIES(loc, vec, label, bitmask) \
- _MASKABLE_EXCEPTION_PSERIES(vec, label, \
- EXC_STD, SOFTEN_TEST_PR, bitmask)
+ __MASKABLE_EXCEPTION_PSERIES(vec, label, \
+ EXC_STD, SOFTEN_TEST_PR, bitmask)
#define MASKABLE_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, vec, bitmask);\
EXCEPTION_PROLOG_2(label, EXC_STD)
#define MASKABLE_EXCEPTION_HV(loc, vec, label, bitmask) \
- _MASKABLE_EXCEPTION_PSERIES(vec, label, \
- EXC_HV, SOFTEN_TEST_HV, bitmask)
+ __MASKABLE_EXCEPTION_PSERIES(vec, label, \
+ EXC_HV, SOFTEN_TEST_HV, bitmask)
#define MASKABLE_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index a5cef69d54b4..67be3e72c7d1 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -770,11 +770,11 @@ EXC_REAL_BEGIN(hardware_interrupt, 0x500, 0x100)
.globl hardware_interrupt_hv;
hardware_interrupt_hv:
BEGIN_FTR_SECTION
- _MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
EXC_HV, SOFTEN_TEST_HV,
IRQS_DISABLED)
FTR_SECTION_ELSE
- _MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
+ __MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt_common,
EXC_STD, SOFTEN_TEST_PR,
IRQS_DISABLED)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
--
2.14.1
^ permalink raw reply related
* [PATCH 11/16] powerpc/64s: Rename EXCEPTION_PROLOG_PSERIES to EXCEPTION_PROLOG
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index b1c445d73165..728532c5f585 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -177,9 +177,9 @@
__EXCEPTION_PROLOG_2_RELON(label, h)
/*
- * As EXCEPTION_PROLOG_PSERIES(), except we've already got relocation on
- * so no need to rfid. Save lr in case we're CONFIG_RELOCATABLE, in which
- * case EXCEPTION_PROLOG_2_RELON will be using LR.
+ * As EXCEPTION_PROLOG(), except we've already got relocation on so no need to
+ * rfid. Save LR in case we're CONFIG_RELOCATABLE, in which case
+ * EXCEPTION_PROLOG_2_RELON will be using LR.
*/
#define EXCEPTION_RELON_PROLOG(area, label, h, extra, vec) \
SET_SCRATCH0(r13); /* save r13 */ \
@@ -343,7 +343,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define EXCEPTION_PROLOG_2_NORI(label, h) \
__EXCEPTION_PROLOG_2_NORI(label, h)
-#define EXCEPTION_PROLOG_PSERIES(area, label, h, extra, vec) \
+#define EXCEPTION_PROLOG(area, label, h, extra, vec) \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
@@ -553,8 +553,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
* Exception vectors.
*/
#define STD_EXCEPTION(vec, label) \
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
- EXC_STD, KVMTEST_PR, vec); \
+ EXCEPTION_PROLOG(PACA_EXGEN, label, EXC_STD, KVMTEST_PR, vec);
/* Version of above for when we have to branch out-of-line */
#define __OOL_EXCEPTION(vec, label, hdlr) \
@@ -567,8 +566,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_PROLOG_2(label, EXC_STD)
#define STD_EXCEPTION_HV(loc, vec, label) \
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
- EXC_HV, KVMTEST_HV, vec);
+ EXCEPTION_PROLOG(PACA_EXGEN, label, EXC_HV, KVMTEST_HV, vec);
#define STD_EXCEPTION_HV_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_HV, vec); \
--
2.14.1
^ permalink raw reply related
* [PATCH 10/16] powerpc/64s: Rename EXCEPTION_RELON_PROLOG_PSERIES
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
To just EXCEPTION_RELON_PROLOG().
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 3674557d58dc..b1c445d73165 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -181,7 +181,7 @@
* so no need to rfid. Save lr in case we're CONFIG_RELOCATABLE, in which
* case EXCEPTION_PROLOG_2_RELON will be using LR.
*/
-#define EXCEPTION_RELON_PROLOG_PSERIES(area, label, h, extra, vec) \
+#define EXCEPTION_RELON_PROLOG(area, label, h, extra, vec) \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
@@ -576,15 +576,14 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_RELON_EXCEPTION(loc, vec, label) \
/* No guest interrupts come through here */ \
- EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
+ EXCEPTION_RELON_PROLOG(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
#define STD_RELON_EXCEPTION_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, NOTEST, vec); \
EXCEPTION_PROLOG_2_RELON(label, EXC_STD)
#define STD_RELON_EXCEPTION_HV(loc, vec, label) \
- EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, \
- EXC_HV, KVMTEST_HV, vec);
+ EXCEPTION_RELON_PROLOG(PACA_EXGEN, label, EXC_HV, KVMTEST_HV, vec);
#define STD_RELON_EXCEPTION_HV_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_HV, vec); \
--
2.14.1
^ permalink raw reply related
* [PATCH 09/16] powerpc/64s: Rename EXCEPTION_RELON_PROLOG_PSERIES_1
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
The EXCEPTION_RELON_PROLOG_PSERIES_1() macro does the same job as
EXCEPTION_PROLOG_2 (which we just recently created), except for
"RELON" (relocation on) exceptions.
So rename it as such.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 445134f3a227..3674557d58dc 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -156,7 +156,7 @@
b hrfi_flush_fallback
#ifdef CONFIG_RELOCATABLE
-#define __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \
+#define __EXCEPTION_PROLOG_2_RELON(label, h) \
mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \
LOAD_HANDLER(r12,label); \
mtctr r12; \
@@ -166,26 +166,26 @@
bctr;
#else
/* If not relocatable, we can jump directly -- and save messing with LR */
-#define __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \
+#define __EXCEPTION_PROLOG_2_RELON(label, h) \
mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \
mfspr r12,SPRN_##h##SRR1; /* and SRR1 */ \
li r10,MSR_RI; \
mtmsrd r10,1; /* Set RI (EE=0) */ \
b label;
#endif
-#define EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \
- __EXCEPTION_RELON_PROLOG_PSERIES_1(label, h) \
+#define EXCEPTION_PROLOG_2_RELON(label, h) \
+ __EXCEPTION_PROLOG_2_RELON(label, h)
/*
* As EXCEPTION_PROLOG_PSERIES(), except we've already got relocation on
* so no need to rfid. Save lr in case we're CONFIG_RELOCATABLE, in which
- * case EXCEPTION_RELON_PROLOG_PSERIES_1 will be using lr.
+ * case EXCEPTION_PROLOG_2_RELON will be using LR.
*/
#define EXCEPTION_RELON_PROLOG_PSERIES(area, label, h, extra, vec) \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
- EXCEPTION_RELON_PROLOG_PSERIES_1(label, h)
+ EXCEPTION_PROLOG_2_RELON(label, h)
/*
* We're short on space and time in the exception prolog, so we can't
@@ -580,7 +580,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_RELON_EXCEPTION_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, NOTEST, vec); \
- EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_STD)
+ EXCEPTION_PROLOG_2_RELON(label, EXC_STD)
#define STD_RELON_EXCEPTION_HV(loc, vec, label) \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, \
@@ -588,7 +588,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_RELON_EXCEPTION_HV_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_HV, vec); \
- EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_HV)
+ EXCEPTION_PROLOG_2_RELON(label, EXC_HV)
/* This associate vector numbers with bits in paca->irq_happened */
#define SOFTEN_VALUE_0x500 PACA_IRQ_EE
@@ -654,7 +654,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
- EXCEPTION_RELON_PROLOG_PSERIES_1(label, h)
+ EXCEPTION_PROLOG_2_RELON(label, h)
#define _MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)\
__MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)
@@ -673,7 +673,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define MASKABLE_RELON_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
- EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_HV)
+ EXCEPTION_PROLOG_2_RELON(label, EXC_HV)
/*
* Our exception common code can be passed various "additions"
--
2.14.1
^ permalink raw reply related
* [PATCH 08/16] powerpc/64s: Remove PSERIES from the NORI macros
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 10 +++++-----
arch/powerpc/kernel/exceptions-64s.S | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 82d137778cb1..445134f3a227 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -329,7 +329,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
__EXCEPTION_PROLOG_2(label, h)
/* _NORI variant keeps MSR_RI clear */
-#define __EXCEPTION_PROLOG_PSERIES_1_NORI(label, h) \
+#define __EXCEPTION_PROLOG_2_NORI(label, h) \
ld r10,PACAKMSR(r13); /* get MSR value for kernel */ \
xori r10,r10,MSR_RI; /* Clear MSR_RI */ \
mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \
@@ -340,8 +340,8 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
h##RFI_TO_KERNEL; \
b . /* prevent speculative execution */
-#define EXCEPTION_PROLOG_PSERIES_1_NORI(label, h) \
- __EXCEPTION_PROLOG_PSERIES_1_NORI(label, h)
+#define EXCEPTION_PROLOG_2_NORI(label, h) \
+ __EXCEPTION_PROLOG_2_NORI(label, h)
#define EXCEPTION_PROLOG_PSERIES(area, label, h, extra, vec) \
SET_SCRATCH0(r13); /* save r13 */ \
@@ -418,10 +418,10 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#endif
/* Do not enable RI */
-#define EXCEPTION_PROLOG_PSERIES_NORI(area, label, h, extra, vec) \
+#define EXCEPTION_PROLOG_NORI(area, label, h, extra, vec) \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
- EXCEPTION_PROLOG_PSERIES_1_NORI(label, h);
+ EXCEPTION_PROLOG_2_NORI(label, h);
#define __KVM_HANDLER(area, h, n) \
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index d1a189f296f3..a5cef69d54b4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -126,8 +126,8 @@ EXC_REAL_BEGIN(system_reset, 0x100, 0x100)
* MSR_RI is not enabled, because PACA_EXNMI and nmi stack is
* being used, so a nested NMI exception would corrupt it.
*/
- EXCEPTION_PROLOG_PSERIES_NORI(PACA_EXNMI, system_reset_common, EXC_STD,
- IDLETEST, 0x100)
+ EXCEPTION_PROLOG_NORI(PACA_EXNMI, system_reset_common, EXC_STD,
+ IDLETEST, 0x100)
EXC_REAL_END(system_reset, 0x100, 0x100)
EXC_VIRT_NONE(0x4100, 0x100)
@@ -230,8 +230,8 @@ EXC_COMMON_BEGIN(system_reset_common)
TRAMP_REAL_BEGIN(system_reset_fwnmi)
SET_SCRATCH0(r13) /* save r13 */
/* See comment at system_reset exception */
- EXCEPTION_PROLOG_PSERIES_NORI(PACA_EXNMI, system_reset_common,
- EXC_STD, NOTEST, 0x100)
+ EXCEPTION_PROLOG_NORI(PACA_EXNMI, system_reset_common, EXC_STD,
+ NOTEST, 0x100)
#endif /* CONFIG_PPC_PSERIES */
@@ -337,7 +337,7 @@ machine_check_pSeries_0:
* nested machine check corrupts it. machine_check_common enables
* MSR_RI.
*/
- EXCEPTION_PROLOG_PSERIES_1_NORI(machine_check_common, EXC_STD)
+ EXCEPTION_PROLOG_2_NORI(machine_check_common, EXC_STD)
TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
--
2.14.1
^ permalink raw reply related
* [PATCH 07/16] powerpc/64s: Rename EXCEPTION_PROLOG_PSERIES_1 to EXCEPTION_PROLOG_2
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
As with the other patches in this series, we are removing the
"PSERIES" from the name as it's no longer meaningful.
In this case it's not simply a case of removing the "PSERIES" as that
would result in a clash with the existing EXCEPTION_PROLOG_1.
Instead we name this one EXCEPTION_PROLOG_2, as it's usually used in
sequence after 0 and 1.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 20 ++++++++++----------
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 1754b0cc0c2f..82d137778cb1 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -316,7 +316,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define EXCEPTION_PROLOG_1(area, extra, vec) \
_EXCEPTION_PROLOG_1(area, extra, vec)
-#define __EXCEPTION_PROLOG_PSERIES_1(label, h) \
+#define __EXCEPTION_PROLOG_2(label, h) \
ld r10,PACAKMSR(r13); /* get MSR value for kernel */ \
mfspr r11,SPRN_##h##SRR0; /* save SRR0 */ \
LOAD_HANDLER(r12,label) \
@@ -325,8 +325,8 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
mtspr SPRN_##h##SRR1,r10; \
h##RFI_TO_KERNEL; \
b . /* prevent speculative execution */
-#define EXCEPTION_PROLOG_PSERIES_1(label, h) \
- __EXCEPTION_PROLOG_PSERIES_1(label, h)
+#define EXCEPTION_PROLOG_2(label, h) \
+ __EXCEPTION_PROLOG_2(label, h)
/* _NORI variant keeps MSR_RI clear */
#define __EXCEPTION_PROLOG_PSERIES_1_NORI(label, h) \
@@ -347,7 +347,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
- EXCEPTION_PROLOG_PSERIES_1(label, h);
+ EXCEPTION_PROLOG_2(label, h);
#define __KVMTEST(h, n) \
lbz r10,HSTATE_IN_GUEST(r13); \
@@ -564,7 +564,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_EXCEPTION_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_PR, vec); \
- EXCEPTION_PROLOG_PSERIES_1(label, EXC_STD)
+ EXCEPTION_PROLOG_2(label, EXC_STD)
#define STD_EXCEPTION_HV(loc, vec, label) \
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
@@ -572,7 +572,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_EXCEPTION_HV_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_HV, vec); \
- EXCEPTION_PROLOG_PSERIES_1(label, EXC_HV)
+ EXCEPTION_PROLOG_2(label, EXC_HV)
#define STD_RELON_EXCEPTION(loc, vec, label) \
/* No guest interrupts come through here */ \
@@ -629,7 +629,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec, bitmask); \
- EXCEPTION_PROLOG_PSERIES_1(label, h);
+ EXCEPTION_PROLOG_2(label, h);
#define _MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra, bitmask) \
__MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra, bitmask)
@@ -640,7 +640,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define MASKABLE_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, vec, bitmask);\
- EXCEPTION_PROLOG_PSERIES_1(label, EXC_STD)
+ EXCEPTION_PROLOG_2(label, EXC_STD)
#define MASKABLE_EXCEPTION_HV(loc, vec, label, bitmask) \
_MASKABLE_EXCEPTION_PSERIES(vec, label, \
@@ -648,7 +648,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define MASKABLE_EXCEPTION_HV_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_HV, vec, bitmask);\
- EXCEPTION_PROLOG_PSERIES_1(label, EXC_HV)
+ EXCEPTION_PROLOG_2(label, EXC_HV)
#define __MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, h, extra, bitmask) \
SET_SCRATCH0(r13); /* save r13 */ \
@@ -665,7 +665,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define MASKABLE_RELON_EXCEPTION_PSERIES_OOL(vec, label, bitmask) \
MASKABLE_EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_NOTEST_PR, vec, bitmask);\
- EXCEPTION_PROLOG_PSERIES_1(label, EXC_STD);
+ EXCEPTION_PROLOG_2(label, EXC_STD);
#define MASKABLE_RELON_EXCEPTION_HV(loc, vec, label, bitmask) \
_MASKABLE_RELON_EXCEPTION_PSERIES(vec, label, \
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index eef60edc5f7f..d1a189f296f3 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1329,7 +1329,7 @@ EXC_REAL_BEGIN(denorm_exception_hv, 0x1500, 0x100)
#endif
KVMTEST_HV(0x1500)
- EXCEPTION_PROLOG_PSERIES_1(denorm_common, EXC_HV)
+ EXCEPTION_PROLOG_2(denorm_common, EXC_HV)
EXC_REAL_END(denorm_exception_hv, 0x1500, 0x100)
#ifdef CONFIG_PPC_DENORMALISATION
@@ -1449,7 +1449,7 @@ EXC_VIRT_NONE(0x5800, 0x100)
std r12,PACA_EXGEN+EX_R12(r13); \
GET_SCRATCH0(r10); \
std r10,PACA_EXGEN+EX_R13(r13); \
- EXCEPTION_PROLOG_PSERIES_1(soft_nmi_common, _H)
+ EXCEPTION_PROLOG_2(soft_nmi_common, _H)
/*
* Branch to soft_nmi_interrupt using the emergency stack. The emergency
--
2.14.1
^ permalink raw reply related
* [PATCH 06/16] powerpc/64s: Rename STD_RELON_EXCEPTION_PSERIES_OOL to STD_RELON_EXCEPTION_OOL
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 5a86173c56b9..1754b0cc0c2f 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -578,7 +578,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
/* No guest interrupts come through here */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
-#define STD_RELON_EXCEPTION_PSERIES_OOL(vec, label) \
+#define STD_RELON_EXCEPTION_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, NOTEST, vec); \
EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_STD)
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index cf0e1ac1149a..640d354a3ab3 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -346,7 +346,7 @@ end_##sname:
#define __TRAMP_VIRT_OOL(name, realvec) \
TRAMP_VIRT_BEGIN(tramp_virt_##name); \
- STD_RELON_EXCEPTION_PSERIES_OOL(realvec, name##_common); \
+ STD_RELON_EXCEPTION_OOL(realvec, name##_common);
#define EXC_VIRT_OOL(name, start, size, realvec) \
__EXC_VIRT_OOL(name, start, size); \
--
2.14.1
^ permalink raw reply related
* [PATCH 05/16] powerpc/64s: Rename STD_RELON_EXCEPTION_PSERIES to STD_RELON_EXCEPTION
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index db8989d4dffb..5a86173c56b9 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -574,7 +574,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_HV, vec); \
EXCEPTION_PROLOG_PSERIES_1(label, EXC_HV)
-#define STD_RELON_EXCEPTION_PSERIES(loc, vec, label) \
+#define STD_RELON_EXCEPTION(loc, vec, label) \
/* No guest interrupts come through here */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index 3e955889f615..cf0e1ac1149a 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -265,7 +265,7 @@ end_##sname:
#define EXC_VIRT(name, start, size, realvec) \
EXC_VIRT_BEGIN(name, start, size); \
- STD_RELON_EXCEPTION_PSERIES(start, realvec, name##_common); \
+ STD_RELON_EXCEPTION(start, realvec, name##_common); \
EXC_VIRT_END(name, start, size);
#define EXC_REAL_MASKABLE(name, start, size, bitmask) \
--
2.14.1
^ permalink raw reply related
* [PATCH 04/16] powerpc/64s: Rename STD_EXCEPTION_PSERIES_OOL to STD_EXCEPTION_OOL
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 9aeafb4d4ff7..db8989d4dffb 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -562,7 +562,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_PROLOG_0(PACA_EXGEN) \
b hdlr;
-#define STD_EXCEPTION_PSERIES_OOL(vec, label) \
+#define STD_EXCEPTION_OOL(vec, label) \
EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST_PR, vec); \
EXCEPTION_PROLOG_PSERIES_1(label, EXC_STD)
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index 66ea28dc21dd..3e955889f615 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -295,7 +295,7 @@ end_##sname:
#define __TRAMP_REAL_OOL(name, vec) \
TRAMP_REAL_BEGIN(tramp_real_##name); \
- STD_EXCEPTION_PSERIES_OOL(vec, name##_common); \
+ STD_EXCEPTION_OOL(vec, name##_common);
#define EXC_REAL_OOL(name, start, size) \
__EXC_REAL_OOL(name, start, size); \
--
2.14.1
^ permalink raw reply related
* [PATCH 03/16] powerpc/64s: Rename STD_EXCEPTION_PSERIES to STD_EXCEPTION
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
The "PSERIES" in STD_EXCEPTION_PSERIES is to differentiate the macros
from the legacy iSeries versions, which are called
STD_EXCEPTION_ISERIES. It is not anything to do with pseries vs
powernv or powermac etc.
We removed the legacy iSeries code in 2012, in commit 8ee3e0d69623x
("powerpc: Remove the main legacy iSerie platform code").
So remove "PSERIES" from the macros.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/head-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index a3027ef75500..9aeafb4d4ff7 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -552,7 +552,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
/*
* Exception vectors.
*/
-#define STD_EXCEPTION_PSERIES(vec, label) \
+#define STD_EXCEPTION(vec, label) \
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label, \
EXC_STD, KVMTEST_PR, vec); \
diff --git a/arch/powerpc/include/asm/head-64.h b/arch/powerpc/include/asm/head-64.h
index 7e0e93f24cb7..66ea28dc21dd 100644
--- a/arch/powerpc/include/asm/head-64.h
+++ b/arch/powerpc/include/asm/head-64.h
@@ -260,7 +260,7 @@ end_##sname:
#define EXC_REAL(name, start, size) \
EXC_REAL_BEGIN(name, start, size); \
- STD_EXCEPTION_PSERIES(start, name##_common); \
+ STD_EXCEPTION(start, name##_common); \
EXC_REAL_END(name, start, size);
#define EXC_VIRT(name, start, size, realvec) \
--
2.14.1
^ permalink raw reply related
* [PATCH 02/16] powerpc/64s: Move SET_SCRATCH0() into EXCEPTION_RELON_PROLOG_PSERIES()
From: Michael Ellerman @ 2018-07-26 13:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin, anton, paulus
In-Reply-To: <20180726130717.18761-1-mpe@ellerman.id.au>
EXCEPTION_RELON_PROLOG_PSERIES() only has two users,
STD_RELON_EXCEPTION_PSERIES() and STD_RELON_EXCEPTION_HV() both of
which "call" SET_SCRATCH0(), so just move SET_SCRATCH0() into
EXCEPTION_RELON_PROLOG_PSERIES().
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index d6932990be15..a3027ef75500 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -182,6 +182,7 @@
* case EXCEPTION_RELON_PROLOG_PSERIES_1 will be using lr.
*/
#define EXCEPTION_RELON_PROLOG_PSERIES(area, label, h, extra, vec) \
+ SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(area); \
EXCEPTION_PROLOG_1(area, extra, vec); \
EXCEPTION_RELON_PROLOG_PSERIES_1(label, h)
@@ -575,7 +576,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
#define STD_RELON_EXCEPTION_PSERIES(loc, vec, label) \
/* No guest interrupts come through here */ \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, EXC_STD, NOTEST, vec);
#define STD_RELON_EXCEPTION_PSERIES_OOL(vec, label) \
@@ -583,7 +583,6 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
EXCEPTION_RELON_PROLOG_PSERIES_1(label, EXC_STD)
#define STD_RELON_EXCEPTION_HV(loc, vec, label) \
- SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_RELON_PROLOG_PSERIES(PACA_EXGEN, label, \
EXC_HV, KVMTEST_HV, vec);
--
2.14.1
^ 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