<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/arch/powerpc/kexec, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/arch/powerpc/kexec?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/arch/powerpc/kexec?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-09-28T09:22:09Z</updated>
<entry>
<title>powerpc/64/kdump: Limit kdump base to 512MB</title>
<updated>2022-09-28T09:22:09Z</updated>
<author>
<name>Hari Bathini</name>
<email>hbathini@linux.ibm.com</email>
</author>
<published>2022-09-12T06:50:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=bd7dc90e52e8db7ee0f38c51bc9047bafb54fe43'/>
<id>urn:sha1:bd7dc90e52e8db7ee0f38c51bc9047bafb54fe43</id>
<content type='text'>
Since commit e641eb03ab2b0 ("powerpc: Fix up the kdump base cap to
128M") memory for kdump kernel has been reserved at an offset of 128MB.
This held up well for a long time before running into boot failure on
LPARs having a lot of cores. Commit 7c5ed82b800d8 ("powerpc: Set
crashkernel offset to mid of RMA region") fixed this boot failure by
moving the offset to mid of RMA region. This change meant the offset is
either 256MB or 512MB on LPARs as ppc64_rma_size was 512MB or 1024MB
owing to commit 103a8542cb35b ("powerpc/book3s64/ radix: Fix boot
failure with large amount of guest memory").

But ppc64_rma_size can be larger as well with newer f/w. So, limit
crashkernel reservation offset to 512MB to avoid running into boot
failures during kdump kernel boot, due to RTAS or other allocation
restrictions.

Also, while here, use SZ_128M instead of opening coding it.

Signed-off-by: Hari Bathini &lt;hbathini@linux.ibm.com&gt;
Tested-by: Sachin Sant &lt;sachinp@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220912065031.57416-1-hbathini@linux.ibm.com

</content>
</entry>
<entry>
<title>powerpc: Remove CONFIG_PPC_BOOK3E</title>
<updated>2022-09-26T13:00:13Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-09-19T17:01:33Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e0d68273d7069537701bb91c51d90d1e12aacc33'/>
<id>urn:sha1:e0d68273d7069537701bb91c51d90d1e12aacc33</id>
<content type='text'>
CONFIG_PPC_BOOK3E is redundant with CONFIG_PPC_BOOK3E_64.

The later is more explicit about the fact that it's a 64 bits target.

Remove CONFIG_PPC_BOOK3E.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/5d0891490813c19cdcfc04678f512ea68cba3e64.1663606876.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>powerpc: Remove CONFIG_FSL_BOOKE</title>
<updated>2022-09-26T12:47:37Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-09-19T17:01:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=dfc3095cec27f402c183da920f4733785e4c873d'/>
<id>urn:sha1:dfc3095cec27f402c183da920f4733785e4c873d</id>
<content type='text'>
PPC_85xx is PPC32 only.
PPC_85xx always selects E500 and is the only PPC32 that
selects E500.
FSL_BOOKE is selected when E500 and PPC32 are selected.

So FSL_BOOKE is redundant with PPC_85xx.

Remove FSL_BOOKE.

And rename four files accordingly.

cpu_setup_fsl_booke.S is not renamed because it is linked to
PPC_FSL_BOOK3E and not to FSL_BOOKE as suggested by its name.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/08e3e15594e66d63b9e89c5b4f9c35153913c28f.1663606875.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>powerpc/kexec: Fix build failure from uninitialised variable</title>
<updated>2022-08-10T05:55:20Z</updated>
<author>
<name>Russell Currey</name>
<email>ruscur@russell.cc</email>
</author>
<published>2022-08-10T05:43:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=83ee9f23763a432a4077bf20624ee35de87bce99'/>
<id>urn:sha1:83ee9f23763a432a4077bf20624ee35de87bce99</id>
<content type='text'>
clang 14 won't build because ret is uninitialised and can be returned if
both prop and fdtprop are NULL.  Drop the ret variable and return an
error in that failure case.

Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window")
Suggested-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Russell Currey &lt;ruscur@russell.cc&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220810054331.373761-1-ruscur@russell.cc

</content>
</entry>
<entry>
<title>powerpc/64e: Fix kexec build error</title>
<updated>2022-08-03T06:32:18Z</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2022-08-03T06:29:41Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4cfa6ff24a9744ba484521c38bea613134fbfcb3'/>
<id>urn:sha1:4cfa6ff24a9744ba484521c38bea613134fbfcb3</id>
<content type='text'>
When building ppc64_book3e_allmodconfig the build fails with:

  arch/powerpc/kexec/file_load_64.c:1063:14: error: implicit declaration of function ‘firmware_has_feature’
   1063 |         if (!firmware_has_feature(FW_FEATURE_LPAR))
        |              ^~~~~~~~~~~~~~~~~~~~

Add a direct include of asm/firmware.h to fix the error.

Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window")
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220803063152.1249270-1-mpe@ellerman.id.au

</content>
</entry>
<entry>
<title>pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window</title>
<updated>2022-07-28T06:22:13Z</updated>
<author>
<name>Alexey Kardashevskiy</name>
<email>aik@ozlabs.ru</email>
</author>
<published>2022-06-29T06:06:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=b1fc44eaa9ba31e28c4125d6b9205a3582b47b5d'/>
<id>urn:sha1:b1fc44eaa9ba31e28c4125d6b9205a3582b47b5d</id>
<content type='text'>
The pseries platform uses 32bit default DMA window (always 4K pages) and
optional 64bit DMA window available via DDW ("Dynamic DMA Windows"),
64K or 2M pages. For ages the default one was not removed and a huge
window was created in addition. Things changed with SRIOV-enabled
PowerVM which creates a default-and-bigger DMA window in 64bit space
(still using 4K pages) for IOV VFs so certain OSes do not need to use
the DDW API in order to utilize all available TCE budget.

Linux on the other hand removes the default window and creates a bigger
one (with more TCEs or/and a bigger page size - 64K/2M) in a bid to map
the entire RAM, and if the new window size is smaller than that - it
still uses this new bigger window. The result is that the default window
is removed but the "ibm,dma-window" property is not.

When kdump is invoked, the existing code tries reusing the existing 64bit
DMA window which location and parameters are stored in the device tree but
this fails as the new property does not make it to the kdump device tree
blob. So the code falls back to the default window which does not exist
anymore although the device tree says that it does. The result of that
is that PCI devices become unusable and cannot be used for kdumping.

This preserves the DMA64 and DIRECT64 properties in the device tree blob
for the crash kernel. Since the crash kernel setup is done after device
drivers are loaded and probed, the proper DMA config is stored at least
for boot time devices.

Because DDW window is optional and the code configures the default window
first, the existing code creates an IOMMU table descriptor for
the non-existing default DMA window. It is harmless for kdump as it does
not touch the actual window (only reads what is mapped and marks those IO
pages as used) but it is bad for kexec which clears it thinking it is
a smaller default window rather than a bigger DDW window.

This removes the "ibm,dma-window" property from the device tree after
a bigger window is created and the crash kernel setup picks it up.

Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping")
Signed-off-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Acked-by: Hari Bathini &lt;hbathini@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220629060614.1680476-1-aik@ozlabs.ru

</content>
</entry>
<entry>
<title>powerpc/crash: save cpu register data in crash_smp_send_stop()</title>
<updated>2022-07-28T06:22:13Z</updated>
<author>
<name>Hari Bathini</name>
<email>hbathini@linux.ibm.com</email>
</author>
<published>2022-06-30T06:49:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c7255058b5430b5c42932383bd8887d591e7973a'/>
<id>urn:sha1:c7255058b5430b5c42932383bd8887d591e7973a</id>
<content type='text'>
During kdump, two set of NMI IPIs are sent to secondary CPUs, if
'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs
to stop the CPUs and the other set to collect register data. Instead,
capture register data for secondary CPUs while stopping them itself.
Also, fallback to smp_send_stop() in case the function gets called
without kdump configured.

Signed-off-by: Hari Bathini &lt;hbathini@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20220630064942.192283-1-hbathini@linux.ibm.com

</content>
</entry>
<entry>
<title>powerpc: Include asm/firmware.h in all users of firmware_has_feature()</title>
<updated>2022-06-29T06:45:05Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-05-06T09:14:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=46d60bdb1283bb0f22d9480e2d6c972623cb4182'/>
<id>urn:sha1:46d60bdb1283bb0f22d9480e2d6c972623cb4182</id>
<content type='text'>
Trying to remove asm/ppc_asm.h from all places that don't need it
leads to several failures linked to firmware_has_feature().

To fix it, include asm/firmware.h in all files using
firmware_has_feature()

All users found with:

	git grep -L "firmware\.h" ` git grep -l "firmware_has_feature("`

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/11956ec181a034b51a881ac9c059eea72c679a73.1651828453.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>powerpc: Don't include asm/setup.h in asm/machdep.h</title>
<updated>2022-06-20T01:29:49Z</updated>
<author>
<name>Christophe Leroy</name>
<email>christophe.leroy@csgroup.eu</email>
</author>
<published>2022-06-11T16:55:15Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=113fe88eed53af08800f54a03e463636105831e0'/>
<id>urn:sha1:113fe88eed53af08800f54a03e463636105831e0</id>
<content type='text'>
asm/machdep.h doesn't need asm/setup.h

Remove it.

Add it directly in files that needs it.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/3b1dfb19a2c3265fb4abc2bfc7b6eae9261a998b.1654966508.git.christophe.leroy@csgroup.eu

</content>
</entry>
<entry>
<title>powerpc/kasan: Mark more real-mode code as not to be instrumented</title>
<updated>2022-05-29T00:30:42Z</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@ozlabs.org</email>
</author>
<published>2022-05-19T07:45:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=743cdb7bd0f1cb32c03680c8b38257957db2e692'/>
<id>urn:sha1:743cdb7bd0f1cb32c03680c8b38257957db2e692</id>
<content type='text'>
This marks more files and functions that can possibly be called in
real mode as not to be instrumented by KASAN.  Most were found by
inspection, except for get_pseries_errorlog() which was reported as
causing a crash in testing.

Reported-by: Nageswara R Sastry &lt;rnsastry@linux.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/YoX1kZPnmUX4RZEK@cleo

</content>
</entry>
</feed>
