Amit Machhiwal writes:
> Currently, rebooting a pseries nested qemu-kvm guest (L2) results in
> below error as L1 qemu sends PVR value 'arch_compat' == 0 via
> ppc_set_compat ioctl. This triggers a condition failure in
> kvmppc_set_arch_compat() resulting in an EINVAL.
>
> qemu-system-ppc64: Unab
David Hildenbrand writes:
>>>
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch() purposes, we'd
not
detect "belongs to this folio batch" either way.
>>>
>>> Exactly
David Hildenbrand writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>
>> If high bits are used for
>> something else, then we might produce a garbage PTE on overflow, but that
>> shouldn't really matter I concluded for folio_pte_batc
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on loongarch with some adjustments.
Here use IS_ENABLED(CONFIG_CRASH_RESERVE) check to decide if compiling
in the crashkernel reservation code.
Signed-off-by:
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on arm with some adjustments.
Here use CONFIG_CRASH_RESERVE ifdef to replace CONFIG_KEXEC ifdef.
Signed-off-by: Baoquan He
---
v2->v3:
- Fix the lkp reported
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on risc-v with some adjustments.
Here wrap up crash dumping codes with CONFIG_CRASH_DUMP ifdeffery, and
use IS_ENABLED(CONFIG_CRASH_RESERVE) check to decide if
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on mips with some adjustments.
Here use IS_ENABLED(CONFIG_CRASH_RESERVE) check to decide if compiling
in the crashkernel reservation code.
Signed-off-by: Baoqu
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on SuperH with some adjustments.
wrap up crash dumping codes with CONFIG_CRASH_DUMP ifdeffery, and
use IS_ENABLED(CONFIG_CRASH_RESERVE) check to decide if compi
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on s390 with some adjustments.
Here wrap up crash dumping codes with CONFIG_CRASH_DUMP ifdeffery.
Signed-off-by: Baoquan He
---
arch/s390/kernel/kexec_elf.c
In PowerPC, the crash dumping and kexec reboot share code in
arch_kexec_locate_mem_hole(), in which struct crash_mem is used.
Here enfoce enforce KEXEC and KEXEC_FILE to select CRASH_DUMP for now.
Signed-off-by: Baoquan He
---
arch/powerpc/Kconfig | 5 +
1 file changed, 5 insertions(+)
dif
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on arm64 with some adjustments.
Here wrap up crash dumping codes with CONFIG_CRASH_DUMP ifdeffery.
Signed-off-by: Baoquan He
---
arch/arm64/include/asm/kexec
Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on x86 with some adjustments.
Here, also change some ifdefs or IS_ENABLED() check to more appropriate
ones, e,g
- #ifdef CONFIG_KEXEC_CORE -> #ifdef CONFIG_CRA
By splitting CRASH_RESERVE and VMCORE_INFO out from CRASH_CORE, cleaning
up the dependency of FA_DMUMP on CRASH_DUMP, and moving crash codes from
kexec_core.c to crash_core.c, now we can rearrange CRASH_DUMP to
depend on KEXEC_CORE, and make CRASH_DUMP select CRASH_RESERVE and
VMCORE_INFO.
KEXEC_C
Currently, KEXEC_CORE select CRASH_CORE automatically because crash codes
need be built in to avoid compiling error when building kexec code even
though the crash dumping functionality is not enabled. E.g
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y
CONFIG_KEXEC_FILE=
In kdump kernel, /proc/vmcore is an elf file mapping the crashed kernel's
old memory content. Its elf header is constructed in 1st kernel and passed
to kdump kernel via elfcorehdr_addr. Config CRASH_DUMP enables the code
of 1st kernel's old memory accessing in different architectures.
Currently, c
Now move the relevant codes into separate files:
kernel/crash_reserve.c, include/linux/crash_reserve.h.
And add config item CRASH_RESERVE to control its enabling.
And also update the old ifdeffery of CONFIG_CRASH_CORE, including of
and config item dependency on CRASH_CORE
accordingly.
And also
Both kdump and fa_dump of ppc rely on crashkernel reservation. Move the
relevant codes into separate files:
crash_reserve.c, include/linux/crash_reserve.h.
And also add config item CRASH_RESERVE to control its enabling of the
codes. And update config items which has relationship with crashkernel
r
Motivation:
=
Previously, LKP reported a building error. When investigating, it can't
be resolved reasonablly with the present messy kdump config items.
https://lore.kernel.org/oe-kbuild-all/202312182200.ka7mzifq-...@intel.com/
The kdump (crash dumping) related config items could cau
Base enablement patch to register performance monitoring hardware
support for Power11. Patch introduce the raw event encoding format,
defines the supported list of events, config fields for the event
attributes and their corresponding bit values which are exported via
sysfs.
Signed-off-by: Madhava
reg.h is updated with Power11 pvr. pvr_mask value of 0x0F07
means we are arch v3.1 compliant. This is used by phyp and
kvm when booting as a pseries guest to detect and enable
the appropriate hwcap, facility bits and PMU related fields.
Copied fields from Power10 table entry and added relevant
On 1/8/24 11:19, Sean Anderson wrote:
> cgr_lock may be locked with interrupts already disabled by
> smp_call_function_single. As such, we must use a raw spinlock to avoid
> problems on PREEMPT_RT kernels. Although this bug has existed for a
> while, it was not apparent until commit ef2a8d5478b9 ("
On 23/01/2024 20:14, David Hildenbrand wrote:
> On 23.01.24 20:43, Ryan Roberts wrote:
>> On 23/01/2024 19:33, David Hildenbrand wrote:
>>> On 23.01.24 20:15, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean
On 23.01.24 20:43, Ryan Roberts wrote:
On 23/01/2024 19:33, David Hildenbrand wrote:
On 23.01.24 20:15, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
Now that the rmap overhaul[1] is upstream that provides a clean interface
for rmap batching, let's implement PTE batching du
On 23/01/2024 19:33, David Hildenbrand wrote:
> On 23.01.24 20:15, Ryan Roberts wrote:
>> On 22/01/2024 19:41, David Hildenbrand wrote:
>>> Now that the rmap overhaul[1] is upstream that provides a clean interface
>>> for rmap batching, let's implement PTE batching during fork when processing
>>> P
On 23.01.24 20:15, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
Now that the rmap overhaul[1] is upstream that provides a clean interface
for rmap batching, let's implement PTE batching during fork when processing
PTE-mapped THPs.
This series is partially based on Ryan's pr
On 22/01/2024 19:41, David Hildenbrand wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean interface
> for rmap batching, let's implement PTE batching during fork when processing
> PTE-mapped THPs.
>
> This series is partially based on Ryan's previous work[2] to implement
> co
Add framer support in the fsl_qmc_hdlc driver in order to be able to
signal carrier changes to the network stack based on the framer status
Also use this framer to provide information related to the E1/T1 line
interface on IF_GET_IFACE and configure the line interface according to
IF_IFACE_{E1,T1}
The QMC HDLC driver provides support for HDLC using the QMC (QUICC
Multichannel Controller) to transfer the HDLC data.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
---
drivers/net/wan/Kconfig| 12 +
drivers/net/wan/Makefile | 1 +
drivers/
After contributing the driver, add myself as the maintainer for the
Freescale QMC HDLC driver.
Signed-off-by: Herve Codina
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..15cd3a8e5866 100644
--- a/MAINTAINERS
+++ b/MAINTAIN
Hi,
This series introduces the QMC HDLC support.
Patches were previously sent as part of a full feature series and were
previously reviewed in that context:
"Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
In order to ease the merge, the full feature series has been split
QMC channels support runtime timeslots changes but nothing is done at
the QMC HDLC driver to handle these changes.
Use existing IFACE ioctl in order to configure the timeslots to use.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
---
drivers/net/wan/fsl_qm
On 23/01/2024 15:01, Matthew Wilcox wrote:
> On Tue, Jan 23, 2024 at 10:34:21AM +, Ryan Roberts wrote:
>>> +#define PFN_PTE_SHIFT PAGE_SHIFT
>>
>> I think this is buggy. And so is the arm64 implementation of set_ptes(). It
>> works fine for 48-bit output address, but for 52-bit OAs
On Tue, Jan 23, 2024 at 10:34:21AM +, Ryan Roberts wrote:
> > +#define PFN_PTE_SHIFT PAGE_SHIFT
>
> I think this is buggy. And so is the arm64 implementation of set_ptes(). It
> works fine for 48-bit output address, but for 52-bit OAs, the high bits are
> not
> kept contigously,
On 23/01/2024 14:13, David Hildenbrand wrote:
>>> Although now I'm wondering if there is a race here... What happens if a
>>> page in
>>> the parent becomes dirty after you have checked it but before you write
>>> protect
>>> it? Isn't that already a problem with the current non-batched version?
On Tue, Jan 23, 2024, at 12:45, Geert Uytterhoeven wrote:
>> 68 error regressions:
>
>> + /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no previous
>> prototype for 'memcons_getc' [-Werror=missing-prototypes]: => 80:5
>> + /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no prev
Although now I'm wondering if there is a race here... What happens if a page in
the parent becomes dirty after you have checked it but before you write protect
it? Isn't that already a problem with the current non-batched version? Why do we
even to preserve dirty in the child for private mappings?
On 23.01.24 14:42, Ryan Roberts wrote:
On 23/01/2024 13:06, David Hildenbrand wrote:
On 23.01.24 13:25, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
Let's ignore these bits: they are irrelevant for fork, and will likely
be irrelevant for upcoming users such as page unmappi
On 23/01/2024 13:06, David Hildenbrand wrote:
> On 23.01.24 13:25, Ryan Roberts wrote:
>> On 22/01/2024 19:41, David Hildenbrand wrote:
>>> Let's ignore these bits: they are irrelevant for fork, and will likely
>>> be irrelevant for upcoming users such as page unmapping.
>>>
>>> Signed-off-by: Davi
On 23.01.24 13:25, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
Let's ignore these bits: they are irrelevant for fork, and will likely
be irrelevant for upcoming users such as page unmapping.
Signed-off-by: David Hildenbrand
---
mm/memory.c | 10 --
1 file chang
From: Arnd Bergmann
These functions are either used in only one file and can just be
makde static or need an #include statement to avoid a warning:
arch/powerpc/platforms/85xx/mpc8536_ds.c:30:13: error: no previous prototype
for 'mpc8536_ds_pic_init' [-Werror=missing-prototypes]
arch/powerpc/pl
From: Arnd Bergmann
ppc64_book3e_allmodconfig has one more driver that triggeres a
few missing-prototypes warnings:
arch/powerpc/sysdev/udbg_memcons.c:44:6: error: no previous prototype for
'memcons_putc' [-Werror=missing-prototypes]
arch/powerpc/sysdev/udbg_memcons.c:57:5: error: no previous p
On 22/01/2024 19:42, David Hildenbrand wrote:
> ... and conditionally return to the caller if any pte except the first one
> is writable. fork() has to make sure to properly write-protect in case any
> PTE is writable. Other users (e.g., page unmaping) won't care.
>
> Signed-off-by: David Hildenbr
On 23/01/2024 12:19, David Hildenbrand wrote:
> [...]
>
>>
>> I wrote some documentation for this (based on Matthew's docs for set_ptes()
>> in
>> my version. Perhaps it makes sense to add it here, given this is overridable
>> by
>> the arch.
>>
>> /**
>> * wrprotect_ptes - Write protect a con
On 22/01/2024 19:41, David Hildenbrand wrote:
> Let's ignore these bits: they are irrelevant for fork, and will likely
> be irrelevant for upcoming users such as page unmapping.
>
> Signed-off-by: David Hildenbrand
> ---
> mm/memory.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletio
[...]
I wrote some documentation for this (based on Matthew's docs for set_ptes() in
my version. Perhaps it makes sense to add it here, given this is overridable by
the arch.
/**
* wrprotect_ptes - Write protect a consecutive set of pages.
* @mm: Address space that the pages are mapped int
On Fri, 2024-01-19 at 13:53 +, Christophe Leroy wrote:
>
> Le 19/01/2024 à 14:41, Matthias Schiffer a écrit :
> > >
> > > Thinking about it once more, can we do even more simple ?
> > >
> > > Why do we need that __setup_cpu_g2() at all ?
> > >
> > > You could just add the following into __s
On 22/01/2024 19:41, David Hildenbrand wrote:
> Let's implement PTE batching when consecutive (present) PTEs map
> consecutive pages of the same large folio, and all other PTE bits besides
> the PFNs are equal.
>
> We will optimize folio_pte_batch() separately, to ignore some other
> PTE bits. Thi
On 23.01.24 12:48, Christophe Leroy wrote:
Le 23/01/2024 à 12:38, Ryan Roberts a écrit :
On 23/01/2024 11:31, David Hildenbrand wrote:
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch(
Le 23/01/2024 à 12:38, Ryan Roberts a écrit :
> On 23/01/2024 11:31, David Hildenbrand wrote:
> If high bits are used for
> something else, then we might produce a garbage PTE on overflow, but that
> shouldn't really matter I concluded for folio_pte_batch() purposes, we'd
>
On Tue, 23 Jan 2024, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.8-rc1[1] compared to v6.7[2].
Summarized:
- build errors: +68/-18
- build warnings: +129/-1487
Happy fixing! ;-)
Thanks to the linux-next team for providing the build servic
On 23/01/2024 11:33, David Hildenbrand wrote:
> On 23.01.24 12:17, Ryan Roberts wrote:
>> On 23/01/2024 11:02, David Hildenbrand wrote:
>>> On 23.01.24 11:48, David Hildenbrand wrote:
On 23.01.24 11:34, Ryan Roberts wrote:
> On 22/01/2024 19:41, David Hildenbrand wrote:
>> We want to m
On 23.01.24 12:38, Ryan Roberts wrote:
On 23/01/2024 11:31, David Hildenbrand wrote:
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
detect "belongs to this folio ba
On 23/01/2024 11:31, David Hildenbrand wrote:
>>>
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch() purposes, we'd
not
detect "belongs to this folio batch" either wa
On 23.01.24 12:17, Ryan Roberts wrote:
On 23/01/2024 11:02, David Hildenbrand wrote:
On 23.01.24 11:48, David Hildenbrand wrote:
On 23.01.24 11:34, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
We want to make use of pte_next_pfn() outside of set_ptes(). Let's
simpliy defi
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
detect "belongs to this folio batch" either way.
Exactly.
Maybe it's likely cleaner to also have a custom pte_next
On 23/01/2024 11:02, David Hildenbrand wrote:
> On 23.01.24 11:48, David Hildenbrand wrote:
>> On 23.01.24 11:34, Ryan Roberts wrote:
>>> On 22/01/2024 19:41, David Hildenbrand wrote:
We want to make use of pte_next_pfn() outside of set_ptes(). Let's
simpliy define PFN_PTE_SHIFT, required
Le 23/01/2024 à 12:08, Ryan Roberts a écrit :
> On 23/01/2024 10:48, David Hildenbrand wrote:
>> On 23.01.24 11:34, Ryan Roberts wrote:
>>> On 22/01/2024 19:41, David Hildenbrand wrote:
We want to make use of pte_next_pfn() outside of set_ptes(). Let's
simpliy define PFN_PTE_SHIFT, requ
Le 23/01/2024 à 11:48, David Hildenbrand a écrit :
> On 23.01.24 11:34, Ryan Roberts wrote:
>> On 22/01/2024 19:41, David Hildenbrand wrote:
>>> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
>>> simpliy define PFN_PTE_SHIFT, required by pte_next_pfn().
>>>
>>> Signed-off-by:
On 23/01/2024 10:48, David Hildenbrand wrote:
> On 23.01.24 11:34, Ryan Roberts wrote:
>> On 22/01/2024 19:41, David Hildenbrand wrote:
>>> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
>>> simpliy define PFN_PTE_SHIFT, required by pte_next_pfn().
>>>
>>> Signed-off-by: David H
On 23.01.24 11:48, David Hildenbrand wrote:
On 23.01.24 11:34, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
We want to make use of pte_next_pfn() outside of set_ptes(). Let's
simpliy define PFN_PTE_SHIFT, required by pte_next_pfn().
Signed-off-by: David Hildenbrand
---
On 23.01.24 11:34, Ryan Roberts wrote:
On 22/01/2024 19:41, David Hildenbrand wrote:
We want to make use of pte_next_pfn() outside of set_ptes(). Let's
simpliy define PFN_PTE_SHIFT, required by pte_next_pfn().
Signed-off-by: David Hildenbrand
---
arch/arm/include/asm/pgtable.h | 2 ++
arc
On 22/01/2024 19:41, David Hildenbrand wrote:
> We already read it, let's just forward it.
>
> This patch is based on work by Ryan Roberts.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Ryan Roberts
> ---
> mm/memory.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> d
On 22/01/2024 19:41, David Hildenbrand wrote:
> Let's prepare for further changes.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Ryan Roberts
> ---
> mm/memory.c | 60 -
> 1 file changed, 32 insertions(+), 28 deletions(-)
>
> diff --git
On 22/01/2024 19:41, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simpliy define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Signed-off-by: David Hildenbrand
> ---
> arch/arm/include/asm/pgtable.h | 2 ++
> arch/arm64/include/asm/pgtable.h
On 11/01/24 4:21 pm, Sourabh Jain wrote:
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to
On 11/01/24 4:21 pm, Sourabh Jain wrote:
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elf
On 11/01/24 7:39 pm, Sourabh Jain wrote:
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated
Regular expression used to match the unit address part should not allow
non-hex numbers.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml| 2 +-
.../devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml| 2 +-
2 files changed, 2 inser
68 matches
Mail list logo
