* [PATCH] powerpc/entry: Disable interrupts before irqentry_exit
From: Shrikanth Hegde @ 2026-06-03 9:55 UTC (permalink / raw)
To: maddy, linuxppc-dev
Cc: sshegde, peterz, tglx, christophe.leroy, linux-kernel, venkat88,
mkchauras
Venkat reported a panic on powerpc-next tree where GENERIC_ENTRY has
been enabled.
kernel BUG at kernel/sched/core.c:7512!
NIP preempt_schedule_irq+0x44/0x118
LR dynamic_irqentry_exit_cond_resched+0x40/0x1a4
Call Trace:
dynamic_irqentry_exit_cond_resched+0x40/0x1a4
do_page_fault+0xc0/0x104
data_access_common_virt+0x210/0x220
This happens since __do_page_fault ends up enabling the interrupts and
it could take significant time such that need_resched could be set. This
leads to schedule call in irqentry_exit leading to the bug.
There are many such irq handlers which enables the interrupts.
Fix it by disabling the irq before calling irqentry_exit. The same
pattern exists today in interrupt_exit_kernel_prepare.
While there, make those BUG_ON into WARN_ON. Interrupt is disabled right
after so it is not that severe. This will still help to catch the
offending callsites.
Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Closes: https://lore.kernel.org/all/7904105b-9dfa-4efd-a5ef-bc0276ed255d@linux.ibm.com/
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
---
This applies on top on powerpc/next tree.
base: 6ed60999d33d '("powerpc: Remove unused functions")'
arch/powerpc/include/asm/entry-common.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/entry-common.h b/arch/powerpc/include/asm/entry-common.h
index de5601282755..7da373a56813 100644
--- a/arch/powerpc/include/asm/entry-common.h
+++ b/arch/powerpc/include/asm/entry-common.h
@@ -253,16 +253,17 @@ static inline void arch_interrupt_enter_prepare(struct pt_regs *regs)
static inline void arch_interrupt_exit_prepare(struct pt_regs *regs)
{
if (user_mode(regs)) {
- BUG_ON(regs_is_unrecoverable(regs));
- BUG_ON(regs_irqs_disabled(regs));
+ WARN_ON(regs_is_unrecoverable(regs));
+ WARN_ON(regs_irqs_disabled(regs));
/*
* We don't need to restore AMR on the way back to userspace for KUAP.
* AMR can only have been unlocked if we interrupted the kernel.
*/
kuap_assert_locked();
-
- local_irq_disable();
}
+
+ /* irqentry_exit expects to be called with interrupts disabled */
+ local_irq_disable();
}
static inline void arch_interrupt_async_enter_prepare(struct pt_regs *regs)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] i2c: cpm: Use platform_get_irq() to retrieve interrupt
From: Rosen Penev @ 2026-06-03 9:38 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-i2c, Jochen Friedrich, Andi Shyti,
open list:FREESCALE I2C CPM DRIVER, open list
In-Reply-To: <63476872-b3be-4564-a748-74757130c50a@kernel.org>
On Wed, Jun 3, 2026 at 1:15 AM Christophe Leroy (CS GROUP)
<chleroy@kernel.org> wrote:
>
>
>
> Le 03/06/2026 à 02:54, Rosen Penev a écrit :
> > Replace irq_of_parse_and_map() with platform_get_irq() as recommended
> > for device-managed IRQ lookup. Properly propagate any errors returned
> > from platform_get_irq(). irq_of_parse_and_map() requires
> > ire_dispose_mapping(), which is missing.
>
> irq_of_parse_and_map() and platform_get_irq() look pretty different, can
> you give more details on how one can replace the other ? (I don't mean
> this is wrong, just I don't have enough details).
My understanding is the latter is higher level and doesn't require
mapping. Just a request from the platform_device machinery for an irq
that it already mapped.
It also supports -EPROBE_DEFER. Probably not relevant here but could
be some day.
>
> >
> > Assisted-by: opencode:big-pickle
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/i2c/busses/i2c-cpm.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> > index 2cb6a233d313..23679c192edc 100644
> > --- a/drivers/i2c/busses/i2c-cpm.c
> > +++ b/drivers/i2c/busses/i2c-cpm.c
> > @@ -434,9 +434,9 @@ static int cpm_i2c_setup(struct cpm_i2c *cpm)
> >
> > init_waitqueue_head(&cpm->i2c_wait);
> >
> > - cpm->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> > - if (!cpm->irq)
> > - return -EINVAL;
> > + cpm->irq = platform_get_irq(ofdev, 0);
> > + if (cpm->irq < 0)
> > + return cpm->irq;
> >
> > /* Install interrupt handler. */
> > ret = request_irq(cpm->irq, cpm_i2c_interrupt, 0, "cpm_i2c",
>
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss
From: Ard Biesheuvel @ 2026-06-03 8:57 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel, Ard Biesheuvel
Cc: Catalin Marinas, kernel-team, linux-kernel, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh, maz
In-Reply-To: <178041415770.4024555.11336437584927054639.b4-ty@kernel.org>
(cc Marc)
On Tue, 2 Jun 2026, at 22:34, Will Deacon wrote:
> On Fri, 29 May 2026 17:01:51 +0200, Ard Biesheuvel wrote:
>> One of the reasons the lack of randomization of the linear map on arm64
>> is considered problematic is the fact that bootloaders adhering to the
>> original arm64 boot protocol (i.e., a substantial fraction of all
>> Android phones) may place the kernel at the base of DRAM, and therefore
>> at the base of the non-randomized linear map. This puts a writable alias
>> of the kernel's data and bss regions at a predictable location, removing
>> the need for an attacker to guess where KASLR mapped the kernel.
>>
>> [...]
>
> It would've been nice to hear from the ppc folks on patch 11, but I've
> picked it up on the assumption that they'll love the negative diff stat.
> Worst case, we can drop/revert stuff if they have late objections.
>
Thanks.
There is a de facto ack from Michael Ellerman in the Link:, which is why
I included it.
Note that Sashiko found an issue with KVM+MTE, where a read-only mapping
of the zero page in the linear map may result in issues:
"""
Does moving the zero page to .rodata (or unmapping/read-only mapping its
linear alias) expose a guest-to-host denial of service with KVM and MTE?
When an MTE-enabled KVM guest reads an unmapped memory address, KVM handles
the stage-2 fault by mapping the host's shared zero page. KVM will then
call sanitise_mte_tags() in arch/arm64/kvm/mmu.c.
Since the PG_mte_tagged flag is never set on the zero page, KVM's
try_page_mte_tagging() succeeds, and it calls mte_clear_page_tags().
This executes the STGM instruction using the zero page's linear map alias.
If this alias is read-only or unmapped, won't the STGM instruction trigger
a synchronous permission fault or translation fault in EL1, causing a host
kernel panic?
"""
Marc seems to think it is legit, so I came up with the following (I'll send
it out separately with another pair of tweaks):
-------8<------------
From: Ard Biesheuvel <ardb@kernel.org>
Subject: [PATCH] arm64: mte: Disregard the zero page explicitly for
manipulating tags
The zero page is conceptually immutable, and will be moved into .rodata
to prevent inadvertent corruption.
Prepare the MTE code for this, by ensuring that the zero page is never
taken into account for tag manipulation, given that those actions will
no longer be permitted on the read-only alias of .rodata in the linear
map.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 7f7b97e09996..093b34944aee 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -80,6 +80,11 @@ static inline bool page_mte_tagged(struct page *page)
*/
static inline bool try_page_mte_tagging(struct page *page)
{
+ extern struct page *__zero_page;
+
+ if (page == __zero_page)
+ return false;
+
VM_WARN_ON_ONCE(folio_test_hugetlb(page_folio(page)));
if (!test_and_set_bit(PG_mte_lock, &page->flags.f))
^ permalink raw reply related
* [PATCH RFT] powerpc/8xx: implement get_direction() in cpm1
From: Bartosz Golaszewski @ 2026-06-03 8:26 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Linus Walleij, Dmitry Torokhov
Cc: brgl, linuxppc-dev, linux-kernel, Bartosz Golaszewski
The lack of get_direction() callbacks in this driver causes GPIOLIB to
emit a warning. Implement them for 16- and 32-bit variants.
Reported-by: Christophe Leroy <chleroy@kernel.org>
Closes: https://lore.kernel.org/all/63487206f6e5a93eaf9f41784317fe99d394312f.1780399750.git.chleroy@kernel.org/
Fixes: ec2cceadfae7 ("gpiolib: normalize the return value of gc->get() on behalf of buggy drivers")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Hi Christophe, please test if this works for you to silence the warning
from GPIO core.
---
arch/powerpc/platforms/8xx/cpm1.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/powerpc/platforms/8xx/cpm1.c b/arch/powerpc/platforms/8xx/cpm1.c
index f00734f0590cf7c7382f808dce27373d9ff3d8bc..b31376bf6778802a7f6b6b499066846b6b1f61e9 100644
--- a/arch/powerpc/platforms/8xx/cpm1.c
+++ b/arch/powerpc/platforms/8xx/cpm1.c
@@ -472,6 +472,18 @@ static int cpm1_gpio16_dir_in(struct gpio_chip *gc, unsigned int gpio)
return 0;
}
+static int cpm1_gpio16_get_direction(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct cpm1_gpio16_chip *cpm1_gc = gpiochip_get_data(gc);
+ struct cpm_ioport16 __iomem *iop = cpm1_gc->regs;
+ u16 pin_mask = 1 << (15 - gpio);
+
+ if (in_be16(&iop->dir) & pin_mask)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
int cpm1_gpiochip_add16(struct device *dev)
{
struct device_node *np = dev->of_node;
@@ -498,6 +510,7 @@ int cpm1_gpiochip_add16(struct device *dev)
gc->ngpio = 16;
gc->direction_input = cpm1_gpio16_dir_in;
gc->direction_output = cpm1_gpio16_dir_out;
+ gc->get_direction = cpm1_gpio16_get_direction;
gc->get = cpm1_gpio16_get;
gc->set = cpm1_gpio16_set;
gc->to_irq = cpm1_gpio16_to_irq;
@@ -604,6 +617,18 @@ static int cpm1_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
return 0;
}
+static int cpm1_gpio32_get_direction(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct cpm1_gpio32_chip *cpm1_gc = gpiochip_get_data(gc);
+ struct cpm_ioport32b __iomem *iop = cpm1_gc->regs;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ if (in_be32(&iop->dir) & pin_mask)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
int cpm1_gpiochip_add32(struct device *dev)
{
struct device_node *np = dev->of_node;
@@ -621,6 +646,7 @@ int cpm1_gpiochip_add32(struct device *dev)
gc->ngpio = 32;
gc->direction_input = cpm1_gpio32_dir_in;
gc->direction_output = cpm1_gpio32_dir_out;
+ gc->get_direction = cpm1_gpio32_get_direction;
gc->get = cpm1_gpio32_get;
gc->set = cpm1_gpio32_set;
gc->parent = dev;
---
base-commit: b7bee4ca5688e30ca50fbc87b1b8f7eed7006c17
change-id: 20260603-powerpc-8xx-cpm1-get-dir-698cefe92647
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] i2c: cpm: Use platform_get_irq() to retrieve interrupt
From: Christophe Leroy (CS GROUP) @ 2026-06-03 8:15 UTC (permalink / raw)
To: Rosen Penev, linux-i2c
Cc: Jochen Friedrich, Andi Shyti, open list:FREESCALE I2C CPM DRIVER,
open list
In-Reply-To: <20260603005455.226882-1-rosenp@gmail.com>
Le 03/06/2026 à 02:54, Rosen Penev a écrit :
> Replace irq_of_parse_and_map() with platform_get_irq() as recommended
> for device-managed IRQ lookup. Properly propagate any errors returned
> from platform_get_irq(). irq_of_parse_and_map() requires
> ire_dispose_mapping(), which is missing.
irq_of_parse_and_map() and platform_get_irq() look pretty different, can
you give more details on how one can replace the other ? (I don't mean
this is wrong, just I don't have enough details).
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/i2c/busses/i2c-cpm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> index 2cb6a233d313..23679c192edc 100644
> --- a/drivers/i2c/busses/i2c-cpm.c
> +++ b/drivers/i2c/busses/i2c-cpm.c
> @@ -434,9 +434,9 @@ static int cpm_i2c_setup(struct cpm_i2c *cpm)
>
> init_waitqueue_head(&cpm->i2c_wait);
>
> - cpm->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> - if (!cpm->irq)
> - return -EINVAL;
> + cpm->irq = platform_get_irq(ofdev, 0);
> + if (cpm->irq < 0)
> + return cpm->irq;
>
> /* Install interrupt handler. */
> ret = request_irq(cpm->irq, cpm_i2c_interrupt, 0, "cpm_i2c",
^ permalink raw reply
* Re: [PATCH] [SCSI] qla2xxx: Handle the INTx not connected while passing through
From: Madhavan Srinivasan @ 2026-06-03 8:12 UTC (permalink / raw)
To: Shivaprasad G Bhat, njavali, GR-QLogic-Storage-Upstream,
James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, alex.williamson, Kyle.Mahlkuch,
linuxppc-dev
In-Reply-To: <177885270578.1573.14283751510936407585.stgit@linux.ibm.com>
On 5/15/26 7:15 PM, Shivaprasad G Bhat wrote:
> The PCI_INTERRUPT_PIN reports if the device supports the INTx.
> However, when the device is assigned to a guest via vfio, the
> PCI_INTERRUPT_PIN is set to 0(i.e none) if the line is not
> connected and|or the platform cannot route the interrupt.
>
> In such cases, the guest PCI_INTERRUPT_PIN is 0 and the port
> number becomes -1(255, uint8_t underflow) for qla[25|27|28]xx and
> qla2031 devices. The flt_region_nvram is never set, and subsequently
> the lun detection fails. Below warnings show the NVRAM configuration
> failure.
>
> []-0073:1: Inconsistent NVRAM checksum=0xffffffc0 id=HCAM version=0x100.
> []-0074:1: Falling back to functioning (yet invalid -- WWPN) defaults.
> []-0076:1: NVRAM configuration failed.
>
> The patch handles the case, and sets the port_no to devfn like
> its done everywhere else.
Any update on this? do you have any comments/concerns that should be
addressed
Maddy
> Reference: commit 2bd42b03ab6b ("vfio/pci: Virtualize zero INTx PIN if no pdev->irq")
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> ---
> drivers/scsi/qla2xxx/qla_os.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
> index 72b1c28e4dae..a8d6a0a021f4 100644
> --- a/drivers/scsi/qla2xxx/qla_os.c
> +++ b/drivers/scsi/qla2xxx/qla_os.c
> @@ -2803,11 +2803,16 @@ qla2x00_set_isp_flags(struct qla_hw_data *ha)
> else {
> /* Get adapter physical port no from interrupt pin register. */
> pci_read_config_byte(ha->pdev, PCI_INTERRUPT_PIN, &ha->port_no);
> - if (IS_QLA25XX(ha) || IS_QLA2031(ha) ||
> - IS_QLA27XX(ha) || IS_QLA28XX(ha))
> - ha->port_no--;
> - else
> - ha->port_no = !(ha->port_no & 1);
> + if (ha->port_no == 0) {
> + /* None of INT[A|B|C|D], may be virtualized by vfio */
> + ha->port_no = PCI_FUNC(ha->pdev->devfn);
> + } else {
> + if (IS_QLA25XX(ha) || IS_QLA2031(ha) ||
> + IS_QLA27XX(ha) || IS_QLA28XX(ha))
> + ha->port_no--;
> + else
> + ha->port_no = !(ha->port_no & 1);
> + }
> }
>
> ql_dbg_pci(ql_dbg_init, ha->pdev, 0x000b,
>
>
^ permalink raw reply
* Re: ppc64le kunit test failure: guest_state_buffer_test
From: Eric Biggers @ 2026-06-03 7:40 UTC (permalink / raw)
To: Vaibhav Jain; +Cc: linuxppc-dev, kvm
In-Reply-To: <87ecioyt6y.fsf@vajain21.in.ibm.com>
On Wed, Jun 03, 2026 at 01:03:09PM +0530, Vaibhav Jain wrote:
> Hi Eric,
>
> Thanks for trying and reporting this. This kunit test depends on
> availablility of Qemu commit 5f7d861e("spapr: nested: Add support for
> reporting Hostwide state counter ") [1] that was merged in v10.0.0.
>
> Since you havent mentioned the qemu version used I assume its a version
> < v10.0.0 . With the qemu patch available you should see this test
> passing with results similar to as originally described in original
> cover letter of the patch series at [2] that introduced this kunit test.
>
> [1] https://gitlab.com/qemu-project/qemu/-/commit/5f7d861e65d90e0446b8f22a0bc859a5d8058ea6
>
> [2] https://lore.kernel.org/all/20250416162740.93143-1-vaibhav@linux.ibm.com/
Nope, it fails even on the master branch of QEMU.
- Eric
^ permalink raw reply
* Re: ppc64le kunit test failure: guest_state_buffer_test
From: Vaibhav Jain @ 2026-06-03 7:33 UTC (permalink / raw)
To: Eric Biggers, linuxppc-dev, kvm
In-Reply-To: <20260603064225.GC18149@sol>
Hi Eric,
Thanks for trying and reporting this. This kunit test depends on
availablility of Qemu commit 5f7d861e("spapr: nested: Add support for
reporting Hostwide state counter ") [1] that was merged in v10.0.0.
Since you havent mentioned the qemu version used I assume its a version
< v10.0.0 . With the qemu patch available you should see this test
passing with results similar to as originally described in original
cover letter of the patch series at [2] that introduced this kunit test.
[1] https://gitlab.com/qemu-project/qemu/-/commit/5f7d861e65d90e0446b8f22a0bc859a5d8058ea6
[2] https://lore.kernel.org/all/20250416162740.93143-1-vaibhav@linux.ibm.com/
Eric Biggers <ebiggers@kernel.org> writes:
> FYI, the KUnit test arch/powerpc/kvm/test-guest-state-buffer.c is
> failing when run in QEMU PPC64LE:
>
> [ 146.554299][ T1] KTAP version 1^M
> [ 146.554348][ T1] # Subtest: guest_state_buffer_test^M
> [ 146.554543][ T1] # module: test_guest_state_buffer^M
> [ 146.554927][ T1] 1..7^M
> [ 146.556873][ T1] ok 1 test_creating_buffer^M
> [ 146.558221][ T1] ok 2 test_adding_element^M
> [ 146.559532][ T1] ok 3 test_gs_bitmap^M
> [ 146.560309][ T1] ok 4 test_gs_parsing^M
> [ 146.561246][ T1] ok 5 test_gs_msg^M
> [ 146.562116][ T1] ok 6 test_gs_hostwide_msg^M
> [ 146.562911][ T428] # test_gs_hostwide_counters: ASSERTION FAILED at arch/powerpc/kvm/test-guest-state-buffer.c:488^M
> [ 146.562911][ T428] Expected rc == 0, but^M
> [ 146.562911][ T428] rc == -2 (0xfffffffffffffffe)^M
> [ 146.563600][ T1] not ok 7 test_gs_hostwide_counters^M
> [ 146.563653][ T1] # guest_state_buffer_test: pass:6 fail:1 skip:0 total:7^M
>
> Tested on next-20260602. I haven't bisected it.
>
> Note that this test is in the defconfig.
>
> - Eric
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* [PATCH 1/1] powerpc/crash: stop watchdogs before booting kdump kernel
From: Sourabh Jain @ 2026-06-03 7:02 UTC (permalink / raw)
To: linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, ritesh.list, shivangu, hbathini, mahesh,
adityag, venkat88, sourabhjain, stable, Mahesh Kumar G
In-Reply-To: <20260603070217.483696-1-sourabhjain@linux.ibm.com>
On pseries LPAR systems, watchdog timers configured from userspace
can remain active after a kernel panic. During panic triggered crash
dump capture, the crashing kernel jumps directly to the kdump kernel
without shutting down userspace services. As a result, active
watchdogs are not stopped before entering the kdump kernel.
If dump capture takes longer than the watchdog timeout, PHYP resets
the LPAR before dump collection completes, resulting in dump capture
failure.
Fix this by issuing the H_WATCHDOG hcall on the crash shutdown path
to stop all active watchdogs before booting the kdump kernel.
Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers")
Reported-by: Mahesh Kumar G <mahe657@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
arch/powerpc/kexec/crash.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index e6539f213b3d..5651523e3a70 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -28,6 +28,7 @@
#include <asm/interrupt.h>
#include <asm/kexec_ranges.h>
#include <asm/crashdump-ppc64.h>
+#include <asm/hvcall.h>
/*
* The primary CPU waits a while for all secondary CPUs to enter. This is to
@@ -352,6 +353,28 @@ int crash_shutdown_unregister(crash_shutdown_t handler)
}
EXPORT_SYMBOL(crash_shutdown_unregister);
+/**
+ * stop_watchdogs - Stop active watchdogs before entering kdump kernel
+ * On pseries LPAR systems, watchdogs configured from userspace remain
+ * active after a kernel panic because userspace services are not shut
+ * down on the kdump crash path. If a watchdog expires while the kdump
+ * kernel is collecting the dump, PHYP resets the LPAR and dump capture
+ * fails
+ *
+ * 0x200UL : watchdog stop operation
+ * -1 : watchdog number, disable all watchdogs
+ */
+static void stop_watchdogs(void)
+{
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ int rc;
+
+ rc = plpar_hcall_norets_notrace(H_WATCHDOG, 0x200UL, -1);
+ if (rc != H_SUCCESS && rc != H_NOOP)
+ pr_warn("crash: failed to stop watchdogs\n");
+ }
+}
+
void default_machine_crash_shutdown(struct pt_regs *regs)
{
volatile unsigned int i;
@@ -360,6 +383,8 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
if (TRAP(regs) == INTERRUPT_SYSTEM_RESET)
is_via_system_reset = 1;
+ stop_watchdogs();
+
if (IS_ENABLED(CONFIG_SMP))
crash_smp_send_stop();
else
--
2.52.0
^ permalink raw reply related
* [PATCH 0/1] powerpc/crash: protect kdump from active watchdogs
From: Sourabh Jain @ 2026-06-03 7:02 UTC (permalink / raw)
To: linuxppc-dev, maddy, mpe
Cc: npiggin, chleroy, ritesh.list, shivangu, hbathini, mahesh,
adityag, venkat88, sourabhjain, stable
On pseries LPAR systems in a high-availability environment using the
SBD[1][2] service, I observed that the system abruptly rebooted before
dump capture could complete.
Further investigation showed that SBD had configured a watchdog with
a 30-second timeout. Since the kernel crashes directly into the
kdump kernel without shutting down userspace services, the watchdog
remained active during dump capture. Once the watchdog timeout
expired, PHYP reset the LPAR, causing dump capture to fail.
The issue was reproducible only when the watchdog was active. Dump
capture completed successfully after disabling the watchdog,
stopping the SBD service, or increasing the watchdog timeout value.
This patch fixes the issue by stopping all active watchdogs on the
crash shutdown path before booting the kdump kernel.
Driver that export the hardware watchdog device is:
drivers/watchdog/pseries-wdt.c
[1] https://github.com/clusterlabs/sbd/blob/main/man/sbd.8.pod.in
[2] https://documentation.suse.com/sle-ha/15-SP4/html/SLE-HA-all/cha-ha-storage-protect.html
This issue can be reproduce using below program:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/watchdog.h>
#define WATCHDOG_DEV "/dev/watchdog"
#define TIMEOUT 10
#define PET_INTERVAL 1
static int wdt_fd = -1;
static void watchdog_close(int disarm)
{
int flags;
if (wdt_fd < 0)
return;
if (disarm) {
flags = WDIOS_DISABLECARD;
if (ioctl(wdt_fd, WDIOC_SETOPTIONS, &flags) < 0)
printf("WDIOS_DISABLECARD failed: %m (nowayout may be set)\n");
else
printf("Watchdog disabled via WDIOS_DISABLECARD\n");
if (write(wdt_fd, "V", 1) < 0)
printf("Magic 'V' write failed: %m\n");
else
printf("Magic 'V' written\n");
} else {
printf("Closing WITHOUT disarming - watchdog keeps running!\n");
}
close(wdt_fd);
wdt_fd = -1;
printf("Watchdog fd closed\n");
}
static void safe_exit(int sig)
{
printf("\nSignal %d received - disarming watchdog...\n", sig);
watchdog_close(1);
exit(0);
}
static int watchdog_init(void)
{
int flags, timeout = TIMEOUT;
struct watchdog_info ident;
printf("Opening %s...\n", WATCHDOG_DEV);
wdt_fd = open(WATCHDOG_DEV, O_WRONLY);
if (wdt_fd < 0) {
printf("Failed to open %s: %m\n", WATCHDOG_DEV);
return -1;
}
printf("Watchdog opened and ARMED\n");
flags = WDIOS_ENABLECARD;
if (ioctl(wdt_fd, WDIOC_SETOPTIONS, &flags) < 0)
/* ENOTTY = driver always enabled, that's fine */
printf("WDIOS_ENABLECARD: %m (ok if ENOTTY)\n");
else
printf("Watchdog enabled via WDIOS_ENABLECARD\n");
if (ioctl(wdt_fd, WDIOC_SETTIMEOUT, &timeout) < 0)
printf("WDIOC_SETTIMEOUT failed: %m\n");
else
printf("Timeout set to %d seconds\n", timeout);
/* verify what the driver actually set */
if (ioctl(wdt_fd, WDIOC_GETTIMEOUT, &timeout) == 0)
printf("Actual timeout : %d seconds\n", timeout);
if (ioctl(wdt_fd, WDIOC_GETSUPPORT, &ident) == 0)
printf("Identity : %s\n", ident.identity);
return 0;
}
static void watchdog_tickle(void)
{
int timeleft = 0;
if (ioctl(wdt_fd, WDIOC_KEEPALIVE, 0) < 0) {
printf("WDIOC_KEEPALIVE failed: %m - falling back to write\n");
write(wdt_fd, "1", 1);
}
if (ioctl(wdt_fd, WDIOC_GETTIMELEFT, &timeleft) == 0)
printf("Petted watchdog. Timeleft: %d sec\n", timeleft);
else
printf("Petted watchdog.\n");
}
int main(void)
{
signal(SIGINT, safe_exit);
signal(SIGTERM, safe_exit);
if (watchdog_init() < 0)
return 1;
printf("\nPetting every %d seconds. Ctrl+C to safely stop.\n\n",
PET_INTERVAL);
while (1) {
watchdog_tickle();
sleep(PET_INTERVAL);
}
return 0;
}
Steps to reproduce the issue:
-----------------------------
1. Insert pseries-wdt driver
2. Compile the above proram and run the binary
3. Crash the kernel
Sourabh Jain (1):
powerpc/crash: stop watchdogs before booting kdump kernel
arch/powerpc/kexec/crash.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
--
2.52.0
^ permalink raw reply
* ppc64le kunit test failure: guest_state_buffer_test
From: Eric Biggers @ 2026-06-03 6:42 UTC (permalink / raw)
To: linuxppc-dev, kvm, Vaibhav Jain
FYI, the KUnit test arch/powerpc/kvm/test-guest-state-buffer.c is
failing when run in QEMU PPC64LE:
[ 146.554299][ T1] KTAP version 1^M
[ 146.554348][ T1] # Subtest: guest_state_buffer_test^M
[ 146.554543][ T1] # module: test_guest_state_buffer^M
[ 146.554927][ T1] 1..7^M
[ 146.556873][ T1] ok 1 test_creating_buffer^M
[ 146.558221][ T1] ok 2 test_adding_element^M
[ 146.559532][ T1] ok 3 test_gs_bitmap^M
[ 146.560309][ T1] ok 4 test_gs_parsing^M
[ 146.561246][ T1] ok 5 test_gs_msg^M
[ 146.562116][ T1] ok 6 test_gs_hostwide_msg^M
[ 146.562911][ T428] # test_gs_hostwide_counters: ASSERTION FAILED at arch/powerpc/kvm/test-guest-state-buffer.c:488^M
[ 146.562911][ T428] Expected rc == 0, but^M
[ 146.562911][ T428] rc == -2 (0xfffffffffffffffe)^M
[ 146.563600][ T1] not ok 7 test_gs_hostwide_counters^M
[ 146.563653][ T1] # guest_state_buffer_test: pass:6 fail:1 skip:0 total:7^M
Tested on next-20260602. I haven't bisected it.
Note that this test is in the defconfig.
- Eric
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Harsh Prateek Bora @ 2026-06-03 6:31 UTC (permalink / raw)
To: Ritesh Harjani (IBM), Madhavan Srinivasan, Vaibhav Jain,
Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <bjdsw43g.ritesh.list@gmail.com>
On 03/06/26 11:35 am, Ritesh Harjani (IBM) wrote:
> Harsh Prateek Bora <harshpb@linux.ibm.com> writes:
>
>>> amit, can you just post this alone as a separate patch, so that we could
>>> pull it for 7.2 merge?
>>>
>>
>> FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
>> series), See b4 am --help for more options to select a subset of patches.
>>
>
> I agree, however as an FYI in this case -
> I had few review comments on PATCH-1 here [1] - which along with the
> commit msg changes, also had a code change involved, so IMO, it's still
> a good idea if Amit can test and send an updated patch separately for this -
> to be pulled in for 7.2.
>
> [1]: https://lore.kernel.org/linuxppc-dev/pl2g6xbz.ritesh.list@gmail.com/
>
>
> Replying to Vaibhav comment here so that we can reach to the conclusion
> at one place.
>
>> Hence IMHO, this patch can be marked for stable tree and potential
>> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
>> tag to this patch
>
> I agree, we need not use a fixes tag then. So, we shall mark this
> with v6.10 tag then.
>
> Cc: stable@vger.kernel.org # v6.10+
>
> (I calculated this based on when Power11 was added:
> git tag --contains c2ed087ed35ca | grep -E "^v" |head -1
> v6.10
> )
Thanks for help with this, Ritesh!
>
> -ritesh
>
^ permalink raw reply
* [PATCH 3/3] powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus
From: Aboorva Devarajan @ 2026-06-03 6:27 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Aboorva Devarajan, Christophe Leroy, linux-kernel,
Sourabh Jain, Ritesh Harjani, Shrikanth Hegde
In-Reply-To: <20260603062743.1152253-1-aboorvad@linux.ibm.com>
kexec_prepare_cpus_wait() calls get_cpu() internally to obtain the
current CPU id. kexec_prepare_cpus() calls kexec_prepare_cpus_wait()
twice -- once for KEXEC_STATE_IRQS_OFF and once for
KEXEC_STATE_REAL_MODE -- but only issues a single put_cpu() at the end,
leaving preempt_count elevated by one extra nesting level.
In practice the imbalance does not trigger a 'scheduling while atomic'
splat because the kexec path is a one-way trip: IRQs are already
disabled, no schedule() occurs after the leak, and
default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET
before jumping into kexec_sequence() which never returns. However the
bookkeeping is still wrong.
kexec_prepare_cpus() calls local_irq_disable()/hard_irq_disable()
before invoking kexec_prepare_cpus_wait(), so the CPU is already pinned
and the get_cpu()/put_cpu() preempt_disable() bracketing is unnecessary.
Only the current CPU id is needed, so replace get_cpu() with
smp_processor_id() and drop the now-unneeded put_cpu().
Fixes: 1fc711f7ffb0 ("powerpc/kexec: Fix race in kexec shutdown")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
arch/powerpc/kexec/core_64.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 825ab8a88f18..d7bdc362d497 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -169,7 +169,7 @@ static void kexec_prepare_cpus_wait(int wait_state)
int my_cpu, i, notified=-1;
hw_breakpoint_disable();
- my_cpu = get_cpu();
+ my_cpu = smp_processor_id();
/* Make sure each CPU has at least made it to the state we need.
*
* FIXME: There is a (slim) chance of a problem if not all of the CPUs
@@ -267,8 +267,6 @@ static void kexec_prepare_cpus(void)
/* after we tell the others to go down */
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
-
- put_cpu();
}
#else /* ! SMP */
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] powerpc/powernv: fix preempt count leak in pnv_kexec_wait_secondaries_down
From: Aboorva Devarajan @ 2026-06-03 6:27 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Aboorva Devarajan, Christophe Leroy, linux-kernel,
Sourabh Jain, Ritesh Harjani, Shrikanth Hegde
In-Reply-To: <20260603062743.1152253-1-aboorvad@linux.ibm.com>
pnv_kexec_wait_secondaries_down() calls get_cpu() to obtain the current
CPU id but never calls the matching put_cpu(), leaking one
preempt_disable() nesting level on every invocation.
In practice the imbalance does not trigger a visible splat because the
kexec teardown path is a one-way trip: IRQs are already disabled, no
schedule() occurs after the leak, and default_machine_kexec() overwrites
preempt_count with HARDIRQ_OFFSET before jumping into kexec_sequence()
which never returns. However the bookkeeping is still wrong.
The function only needs the current CPU id, and this path runs with the
CPU pinned and IRQs disabled, so the preempt_disable() side-effect of
get_cpu() is unnecessary. Replace it with smp_processor_id(), which
returns the CPU id without touching preempt_count.
Fixes: 298b34d7d578 ("powerpc/powernv: Fix kexec races going back to OPAL")
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
arch/powerpc/platforms/powernv/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 4dbb47ddbdcc..73193264cbe7 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -396,7 +396,7 @@ static void pnv_kexec_wait_secondaries_down(void)
{
int my_cpu, i, notified = -1;
- my_cpu = get_cpu();
+ my_cpu = smp_processor_id();
for_each_online_cpu(i) {
uint8_t status;
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del
From: Aboorva Devarajan @ 2026-06-03 6:27 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Aboorva Devarajan, Christophe Leroy, linux-kernel,
Sourabh Jain, Ritesh Harjani, Shrikanth Hegde
In-Reply-To: <20260603062743.1152253-1-aboorvad@linux.ibm.com>
fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at
the 'out:' label, but only calls the matching get_cpu_var() after the
'i < 0' early-return check. When event->hw.idx is negative the
function jumps to 'out:' without having taken get_cpu_var(), and the
trailing put_cpu_var() then issues an unmatched preempt_enable(),
underflowing preempt_count.
On a CONFIG_PREEMPT=y kernel preempt_count would underflow and
eventually present as a 'scheduling while atomic' BUG.
Move put_cpu_var() to pair with get_cpu_var() so the percpu access is
correctly bracketed and the 'out:' label only handles perf_pmu_enable.
Fixes: a11106544f33 ("powerpc/perf: e500 support")
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
---
arch/powerpc/perf/core-fsl-emb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-fsl-emb.c b/arch/powerpc/perf/core-fsl-emb.c
index 7120ab20cbfe..02b5dd74c187 100644
--- a/arch/powerpc/perf/core-fsl-emb.c
+++ b/arch/powerpc/perf/core-fsl-emb.c
@@ -366,9 +366,10 @@ static void fsl_emb_pmu_del(struct perf_event *event, int flags)
cpuhw->n_events--;
+ put_cpu_var(cpu_hw_events);
+
out:
perf_pmu_enable(event->pmu);
- put_cpu_var(cpu_hw_events);
}
static void fsl_emb_pmu_start(struct perf_event *event, int ef_flags)
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/3] powerpc: fix preempt_count imbalances in perf and kexec paths
From: Aboorva Devarajan @ 2026-06-03 6:27 UTC (permalink / raw)
To: Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Aboorva Devarajan, Christophe Leroy, linux-kernel,
Sourabh Jain, Ritesh Harjani, Shrikanth Hegde
Hi all,
This patch series fixes some minor preempt_count bookkeeping issues in
arch/powerpc/ found during a preemption leak audit prompted by the
lazy/full preemption model changes. These are get_cpu/put_cpu and
get_cpu_var/put_cpu_var pairing errors that leave preempt_count
incorrectly elevated or underflowed.
v1: https://lore.kernel.org/all/20260518050855.1147242-1-aboorvad@linux.ibm.com/
v1 -> v2:
- Patch 1 (fsl_emb_pmu_del): no functional change; picked up
Shrikanth's Reviewed-by.
- Patch 2 (pnv_kexec_wait_secondaries_down): per Shrikanth's review,
use smp_processor_id() instead of raw_smp_processor_id(). The kexec/
crash teardown path runs with IRQs disabled so it is safe.
- Patch 3 (kexec_prepare_cpus): per Shrikanth's review, dropped the
approach of passing the cpu id through kexec_prepare_cpus_wait() as
a parameter. kexec_prepare_cpus() already runs local_irq_disable()/
hard_irq_disable() before the wait, so get_cpu()/put_cpu() is
unnecessary: just read the cpu id in kexec_prepare_cpus_wait() and
drop the trailing put_cpu(). This keeps the function signature
unchanged. smp_processor_id() is used here too, consistent with patch 2.
Testing:
- Patch 1: compile-tested only (ppc64e_defconfig + CONFIG_FSL_EMB_PERFMON);
no e500/fsl_emb hardware to runtime-test so far.
- Patches 2 and 3: kexec boot-tested on PowerNV (powernv_defconfig)
and pseries (pseries_defconfig).
Please let me know your comments.
Thanks,
Aboorva
Aboorva Devarajan (3):
powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del
powerpc/powernv: fix preempt count leak in
pnv_kexec_wait_secondaries_down
powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus
arch/powerpc/kexec/core_64.c | 4 +---
arch/powerpc/perf/core-fsl-emb.c | 3 ++-
arch/powerpc/platforms/powernv/setup.c | 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Ritesh Harjani @ 2026-06-03 6:05 UTC (permalink / raw)
To: Harsh Prateek Bora, Madhavan Srinivasan, Vaibhav Jain,
Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <56c84e26-69ed-433b-baaf-7b53acc60391@linux.ibm.com>
Harsh Prateek Bora <harshpb@linux.ibm.com> writes:
>> amit, can you just post this alone as a separate patch, so that we could
>> pull it for 7.2 merge?
>>
>
> FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
> series), See b4 am --help for more options to select a subset of patches.
>
I agree, however as an FYI in this case -
I had few review comments on PATCH-1 here [1] - which along with the
commit msg changes, also had a code change involved, so IMO, it's still
a good idea if Amit can test and send an updated patch separately for this -
to be pulled in for 7.2.
[1]: https://lore.kernel.org/linuxppc-dev/pl2g6xbz.ritesh.list@gmail.com/
Replying to Vaibhav comment here so that we can reach to the conclusion
at one place.
> Hence IMHO, this patch can be marked for stable tree and potential
> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
> tag to this patch
I agree, we need not use a fixes tag then. So, we shall mark this
with v6.10 tag then.
Cc: stable@vger.kernel.org # v6.10+
(I calculated this based on when Power11 was added:
git tag --contains c2ed087ed35ca | grep -E "^v" |head -1
v6.10
)
-ritesh
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: fix preempt_count imbalances in perf and kexec paths
From: Aboorva Devarajan @ 2026-06-03 6:16 UTC (permalink / raw)
To: Shrikanth Hegde, Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Christophe Leroy, linux-kernel, Sourabh Jain,
Ritesh Harjani
In-Reply-To: <0c6d2855-61df-4fd2-bede-0c204f4fd2b1@linux.ibm.com>
On Mon, 2026-05-18 at 13:38 +0530, Shrikanth Hegde wrote:
> Hi Aboorva,
>
> On 5/18/26 10:38 AM, Aboorva Devarajan wrote:
> > Hi all,
> >
> > This patch series fixes some minor preempt_count bookkeeping issues in
> > arch/powerpc/ found during a preemption leak audit prompted by the
> > lazy/full preemption model changes. These are get_cpu/put_cpu and
> > get_cpu_var/put_cpu_var pairing errors that leave preempt_count
> > incorrectly elevated or underflowed.
> >
>
> Thanks for fixing some of these.
>
> while we do this, Can you fix these mismatch in preempt disable/enable in
> below files as well.
>
> 1. kernel/kprobes.c - kprobe_handler - Does disable, but doesn't enable in some return paths.
> A definite leak.
>
> 2. Maybe platforms/pseries/lpar.c and platforms/powernv/opal-tracepoints.c.
> In __trace_hcall_entry/exit. It maybe a very corner case,
> I don't see a big concern there. But it may be remotely possible.
> Need to evaluate whether it should be fixed or not.
Thanks for the pointers. I'll go through these and get back.
Regards,
Aboorva
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus
From: Shrikanth Hegde @ 2026-06-03 6:16 UTC (permalink / raw)
To: Aboorva Devarajan, Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Christophe Leroy, linux-kernel, Sourabh Jain,
Ritesh Harjani
In-Reply-To: <786b3540efcd83eed95f5e4fb2e7bd9fbd917474.camel@linux.ibm.com>
On 6/3/26 11:44 AM, Aboorva Devarajan wrote:
> Hi Shrikanth,
>
> On Mon, 2026-05-18 at 11:32 +0530, Shrikanth Hegde wrote:
>> Hi Aboorva.
>>
>> On 5/18/26 10:38 AM, Aboorva Devarajan wrote:
>>> kexec_prepare_cpus_wait() calls get_cpu() internally to obtain the
>>> current CPU id. kexec_prepare_cpus() calls kexec_prepare_cpus_wait()
>>> twice -- once for KEXEC_STATE_IRQS_OFF and once for
>>> KEXEC_STATE_REAL_MODE -- but only issues a single put_cpu() at the end,
>>> leaving preempt_count elevated by one extra nesting level.
>>>
>>> In practice the imbalance does not trigger a 'scheduling while atomic'
>>> splat because the kexec path is a one-way trip: IRQs are already
>>> disabled, no schedule() occurs after the leak, and
>>> default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET
>>> before jumping into kexec_sequence() which never returns. However the
>>> bookkeeping is still wrong.
>>>
>>> Lift the get_cpu()/put_cpu() pair into kexec_prepare_cpus() so it is
>>> called exactly once, and pass the CPU id to kexec_prepare_cpus_wait()
>>> as a parameter. This keeps preempt_count correctly balanced.
>>>
>>> Fixes: 1fc711f7ffb01 ("powerpc/kexec: Fix race in kexec shutdown")
>>> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>>> ---
>>> arch/powerpc/kexec/core_64.c | 15 ++++++++-------
>>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
>>> index 825ab8a88f18e..9d7e5a1e6e5b8 100644
>>> --- a/arch/powerpc/kexec/core_64.c
>>> +++ b/arch/powerpc/kexec/core_64.c
>>> @@ -164,12 +164,11 @@ static void kexec_smp_down(void *arg)
>>> /* NOTREACHED */
>>> }
>>>
>>> -static void kexec_prepare_cpus_wait(int wait_state)
>>> +static void kexec_prepare_cpus_wait(int wait_state, int my_cpu)
>>> {
>>> - int my_cpu, i, notified=-1;
>>> + int i, notified = -1;
>>>
>>> hw_breakpoint_disable();
>>> - my_cpu = get_cpu();
>>> /* Make sure each CPU has at least made it to the state we need.
>>> *
>>> * FIXME: There is a (slim) chance of a problem if not all of the CPUs
>>> @@ -246,6 +245,8 @@ static void wake_offline_cpus(void)
>>>
>>> static void kexec_prepare_cpus(void)
>>> {
>>> + int my_cpu;
>>> +
>>> wake_offline_cpus();
>>> smp_call_function(kexec_smp_down, NULL, /* wait */0);
>>> local_irq_disable();
>>> @@ -254,7 +255,8 @@ static void kexec_prepare_cpus(void)
>>> mb(); /* make sure IRQs are disabled before we say they are */
>>> get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
>>>
>>> - kexec_prepare_cpus_wait(KEXEC_STATE_IRQS_OFF);
>>> + my_cpu = get_cpu();
>
>> raw_smp_processor_id() is better here. All it needs is get current cpu?
>> caller does irq_disable above and that renders call for get_cpu un-necessary.
>
> Agreed, get_cpu() is not needed here. kexec_prepare_cpus() already does
> local_irq_disable()/hard_irq_disable() before calling
> kexec_prepare_cpus_wait(), so we only need the current cpu id.
>
> I will go ahead with smp_processor_id() rather than
> raw_smp_processor_id() to stay consistent with Patch 2 and to keep the
> CONFIG_DEBUG_PREEMPT check.
If the irq's are disabled then use raw_smp_processor_id() in both the places.
For patch2, just put a comment saying irq's are disabled when its get there.
>
>>>
>>> @@ -262,13 +264,12 @@ static void kexec_prepare_cpus(void)
>>> * Before removing MMU mappings make sure all CPUs have entered real
>>> * mode:
>>> */
>>> - kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
>>> + kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE, my_cpu);
>>> + put_cpu();
>>>
>>> /* after we tell the others to go down */
>>> if (ppc_md.kexec_cpu_down)
>>> ppc_md.kexec_cpu_down(0, 0);
>>> -
>>> - put_cpu();
>>> }
>>>
>>> #else /* ! SMP */
>
> Regards,
> Aboorva
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus
From: Aboorva Devarajan @ 2026-06-03 6:14 UTC (permalink / raw)
To: Shrikanth Hegde, Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Christophe Leroy, linux-kernel, Sourabh Jain,
Ritesh Harjani
In-Reply-To: <45af9f95-da07-45b6-babe-dbae0f7eb318@linux.ibm.com>
Hi Shrikanth,
On Mon, 2026-05-18 at 11:32 +0530, Shrikanth Hegde wrote:
> Hi Aboorva.
>
> On 5/18/26 10:38 AM, Aboorva Devarajan wrote:
> > kexec_prepare_cpus_wait() calls get_cpu() internally to obtain the
> > current CPU id. kexec_prepare_cpus() calls kexec_prepare_cpus_wait()
> > twice -- once for KEXEC_STATE_IRQS_OFF and once for
> > KEXEC_STATE_REAL_MODE -- but only issues a single put_cpu() at the end,
> > leaving preempt_count elevated by one extra nesting level.
> >
> > In practice the imbalance does not trigger a 'scheduling while atomic'
> > splat because the kexec path is a one-way trip: IRQs are already
> > disabled, no schedule() occurs after the leak, and
> > default_machine_kexec() overwrites preempt_count with HARDIRQ_OFFSET
> > before jumping into kexec_sequence() which never returns. However the
> > bookkeeping is still wrong.
> >
> > Lift the get_cpu()/put_cpu() pair into kexec_prepare_cpus() so it is
> > called exactly once, and pass the CPU id to kexec_prepare_cpus_wait()
> > as a parameter. This keeps preempt_count correctly balanced.
> >
> > Fixes: 1fc711f7ffb01 ("powerpc/kexec: Fix race in kexec shutdown")
> > Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> > ---
> > arch/powerpc/kexec/core_64.c | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
> > index 825ab8a88f18e..9d7e5a1e6e5b8 100644
> > --- a/arch/powerpc/kexec/core_64.c
> > +++ b/arch/powerpc/kexec/core_64.c
> > @@ -164,12 +164,11 @@ static void kexec_smp_down(void *arg)
> > /* NOTREACHED */
> > }
> >
> > -static void kexec_prepare_cpus_wait(int wait_state)
> > +static void kexec_prepare_cpus_wait(int wait_state, int my_cpu)
> > {
> > - int my_cpu, i, notified=-1;
> > + int i, notified = -1;
> >
> > hw_breakpoint_disable();
> > - my_cpu = get_cpu();
> > /* Make sure each CPU has at least made it to the state we need.
> > *
> > * FIXME: There is a (slim) chance of a problem if not all of the CPUs
> > @@ -246,6 +245,8 @@ static void wake_offline_cpus(void)
> >
> > static void kexec_prepare_cpus(void)
> > {
> > + int my_cpu;
> > +
> > wake_offline_cpus();
> > smp_call_function(kexec_smp_down, NULL, /* wait */0);
> > local_irq_disable();
> > @@ -254,7 +255,8 @@ static void kexec_prepare_cpus(void)
> > mb(); /* make sure IRQs are disabled before we say they are */
> > get_paca()->kexec_state = KEXEC_STATE_IRQS_OFF;
> >
> > - kexec_prepare_cpus_wait(KEXEC_STATE_IRQS_OFF);
> > + my_cpu = get_cpu();
> raw_smp_processor_id() is better here. All it needs is get current cpu?
> caller does irq_disable above and that renders call for get_cpu un-necessary.
Agreed, get_cpu() is not needed here. kexec_prepare_cpus() already does
local_irq_disable()/hard_irq_disable() before calling
kexec_prepare_cpus_wait(), so we only need the current cpu id.
I will go ahead with smp_processor_id() rather than
raw_smp_processor_id() to stay consistent with Patch 2 and to keep the
CONFIG_DEBUG_PREEMPT check.
> >
> > @@ -262,13 +264,12 @@ static void kexec_prepare_cpus(void)
> > * Before removing MMU mappings make sure all CPUs have entered real
> > * mode:
> > */
> > - kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
> > + kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE, my_cpu);
> > + put_cpu();
> >
> > /* after we tell the others to go down */
> > if (ppc_md.kexec_cpu_down)
> > ppc_md.kexec_cpu_down(0, 0);
> > -
> > - put_cpu();
> > }
> >
> > #else /* ! SMP */
Regards,
Aboorva
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/powernv: fix preempt count leak in pnv_kexec_wait_secondaries_down
From: Aboorva Devarajan @ 2026-06-03 6:08 UTC (permalink / raw)
To: Shrikanth Hegde, Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Christophe Leroy, linux-kernel, Sourabh Jain,
Ritesh Harjani
In-Reply-To: <99da8dfa-2624-44fb-96c5-ff7eddf717ac@linux.ibm.com>
On Mon, 2026-05-18 at 13:26 +0530, Shrikanth Hegde wrote:
>
> Hi Aboorva.
>
> On 5/18/26 10:38 AM, Aboorva Devarajan wrote:
> > pnv_kexec_wait_secondaries_down() calls get_cpu() to obtain the current
> > CPU id but never calls the matching put_cpu(), leaking one
> > preempt_disable() nesting level on every invocation.
> >
> > In practice the imbalance does not trigger a visible splat because the
> > kexec teardown path is a one-way trip: IRQs are already disabled, no
> > schedule() occurs after the leak, and default_machine_kexec() overwrites
> > preempt_count with HARDIRQ_OFFSET before jumping into kexec_sequence()
> > which never returns. However the bookkeeping is still wrong.
> >
> > In the kexec teardown path IRQs are already disabled and the CPU is
> > pinned, so get_cpu()'s preempt_disable() side-effect is unnecessary.
> > Replace get_cpu() with raw_smp_processor_id() which returns the CPU id
> > without touching preempt_count.
> >
> > Fixes: 298b34d7d578 ("powerpc/powernv: Fix kexec races going back to OPAL")
> > Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> > ---
> > arch/powerpc/platforms/powernv/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> > index 4dbb47ddbdcc4..177da0defcb36 100644
> > --- a/arch/powerpc/platforms/powernv/setup.c
> > +++ b/arch/powerpc/platforms/powernv/setup.c
> > @@ -396,7 +396,7 @@ static void pnv_kexec_wait_secondaries_down(void)
> > {
> > int my_cpu, i, notified = -1;
> >
> > - my_cpu = get_cpu();
> > + my_cpu = raw_smp_processor_id();
> >
>
> Is it always with irq-disabled?
> How about !CONFIG_SMP and in kexec_prepare_cpus. I see it disables interrupt later.
> (though it is a less common config)
>
IIUC, PPC_POWERNV does 'select FORCE_SMP' (-> selects SMP), so there is no
!CONFIG_SMP powernv build. The !SMP kexec_prepare_cpus() variant in
arch/powerpc/kexec/core_64.c, the one you spotted that calls
ppc_md.kexec_cpu_down() before local_irq_disable() is therefore
never compiled with powernv, so pnv_kexec_cpu_down() ->
pnv_kexec_wait_secondaries_down() can't be reached through it.
so, IRQs are disabled in every case that reaches this function.
> So use smp_processor_id()?? One could compile with CONFIG_DEBUG_PREEMPT=y and
> see any reports.
>
> > for_each_online_cpu(i) {
> > uint8_t status;
sure, I'll switch to smp_processor_id() in v2 rather than raw_smp_processor_id().
It returns the cpu id without touching preempt_count (so the leak is
gone), and unlike the raw variant it keeps the CONFIG_DEBUG_PREEMPT
check which is a no-op here since IRQs are off, but will flag any
future caller that reaches this path while preemptible instead of
silently hiding it.
Thanks,
Aboorva
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del
From: Aboorva Devarajan @ 2026-06-03 5:59 UTC (permalink / raw)
To: Shrikanth Hegde, Madhavan Srinivasan, linuxppc-dev
Cc: Athira Rajeev, Christophe Leroy, linux-kernel, Sourabh Jain,
Ritesh Harjani
In-Reply-To: <1e31821a-2c9d-4394-83b4-e850f96ad662@linux.ibm.com>
On Mon, 2026-05-18 at 11:43 +0530, Shrikanth Hegde wrote:
>
>
> On 5/18/26 10:38 AM, Aboorva Devarajan wrote:
> > fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events)
> > at
> > the 'out:' label, but only calls the matching get_cpu_var() after
> > the
> > 'i < 0' early-return check. When event->hw.idx is negative the
> > function jumps to 'out:' without having taken get_cpu_var(), and
> > the
> > trailing put_cpu_var() then issues an unmatched preempt_enable(),
> > underflowing preempt_count.
> >
> > On a CONFIG_PREEMPT=y kernel preempt_count would underflow and
> > eventually present as a 'scheduling while atomic' BUG.
> >
> > Move put_cpu_var() to pair with get_cpu_var() so the percpu access
> > is
> > correctly bracketed and the 'out:' label only handles
> > perf_pmu_enable.
> >
> > Fixes: a11106544f33c ("powerpc/perf: e500 support")
> > Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> > ---
> > arch/powerpc/perf/core-fsl-emb.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/perf/core-fsl-emb.c
> > b/arch/powerpc/perf/core-fsl-emb.c
> > index 7120ab20cbfec..02b5dd74c187a 100644
> > --- a/arch/powerpc/perf/core-fsl-emb.c
> > +++ b/arch/powerpc/perf/core-fsl-emb.c
> > @@ -366,9 +366,10 @@ static void fsl_emb_pmu_del(struct perf_event
> > *event, int flags)
> >
> > cpuhw->n_events--;
> >
> > + put_cpu_var(cpu_hw_events);
> > +
> > out:
> > perf_pmu_enable(event->pmu);
> > - put_cpu_var(cpu_hw_events);
> > }
> >
> > static void fsl_emb_pmu_start(struct perf_event *event, int
> > ef_flags)
>
> Thanks for fixing this. Looks good to me.
>
> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Hi Shrikanth,
Thanks for the review.
Regards,
Aboorva
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Harsh Prateek Bora @ 2026-06-03 5:10 UTC (permalink / raw)
To: Madhavan Srinivasan, Vaibhav Jain, Ritesh Harjani, Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <72ef4cdb-8d9e-4319-9c94-b9a46a6f6194@linux.ibm.com>
On 03/06/26 10:03 am, Madhavan Srinivasan wrote:
>
> On 6/3/26 9:03 AM, Vaibhav Jain wrote:
>> Hi Ritesh, thanks for looking into this patch. My responses to your
>> review comments inline below.
>>
>> Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
>>
>>> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>>>
>>>> So, we would still want to prioritize the whole series
>>>> instead of just this one patch.
>>>>
>>> Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
>>> bug fixes). - Maddy?
>>>
>>> So, you may want to add a fixes tag and maybe even cc stable if you are
>>> seeing this issue from older kernels maybe when nestedv2 got introduced?
>> This isnt a 'bug fix' per-se but rather strengthening of compat mode
>> checks so that any non compatible PVR being used by the VMM can be
>> caught early. The hypervisor anyway ultimately prevents non-compatible
>> PVRs from being used by the VMM. So there isnt a bug thats being fixed
>> in this patch.
>>
>> The rest of the patch series builds on top of this patch to advertise
>> the available compatible PVRs to the VMM so that it can further
>> preemptively prevent users from forcibly using a non-compatible PVR.
>>
>> Hence IMHO, this patch can be marked for stable tree and potential
>> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
>> tag to this patch
> amit, can you just post this alone as a separate patch, so that we could
> pull it for 7.2 merge?
>
FWIW, b4 am -P1 <mbox> should fetch this patch alone (and not the entire
series), See b4 am --help for more options to select a subset of patches.
regards,
Harsh>
>>> However the new UAPI discussion might still require more discussion with
>>> the community and I don't think it is ready for 7.2 yet ;)
>> Somewhat agree with the above
>>
>>> -ritesh
>>>
>
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Madhavan Srinivasan @ 2026-06-03 4:33 UTC (permalink / raw)
To: Vaibhav Jain, Ritesh Harjani, Amit Machhiwal
Cc: linuxppc-dev, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <87se74z4a6.fsf@vajain21.in.ibm.com>
On 6/3/26 9:03 AM, Vaibhav Jain wrote:
> Hi Ritesh, thanks for looking into this patch. My responses to your
> review comments inline below.
>
> Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:
>
>> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>>
>>> So, we would still want to prioritize the whole series
>>> instead of just this one patch.
>>>
>> Patch-1 could go as a bug fix even in 7.1-rc6 (or maybe with 7.2
>> bug fixes). - Maddy?
>>
>> So, you may want to add a fixes tag and maybe even cc stable if you are
>> seeing this issue from older kernels maybe when nestedv2 got introduced?
> This isnt a 'bug fix' per-se but rather strengthening of compat mode
> checks so that any non compatible PVR being used by the VMM can be
> caught early. The hypervisor anyway ultimately prevents non-compatible
> PVRs from being used by the VMM. So there isnt a bug thats being fixed
> in this patch.
>
> The rest of the patch series builds on top of this patch to advertise
> the available compatible PVRs to the VMM so that it can further
> preemptively prevent users from forcibly using a non-compatible PVR.
>
> Hence IMHO, this patch can be marked for stable tree and potential
> candidate for 7.2 merge window. But dont see applicability of a 'fixes'
> tag to this patch
amit, can you just post this alone as a separate patch, so that we could
pull it for 7.2 merge?
>> However the new UAPI discussion might still require more discussion with
>> the community and I don't think it is ready for 7.2 yet ;)
> Somewhat agree with the above
>
>> -ritesh
>>
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV
From: Vaibhav Jain @ 2026-06-03 4:17 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Anushree Mathur, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc, lkp
In-Reply-To: <20260522152744.55251-5-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for the patch. My review comments inline:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
> hypervisor (L0), the guest runs with the expected processor
> compatibility level. However, when booting a nested KVM guest (L2)
> inside the L1, QEMU derives the CPU model from the raw host PVR and
> attempts to run the nested guest at that level, instead of honoring the
> compatibility mode of the L1.
>
> Extend host CPU compatibility capability reporting to support nested
> virtualization on PowerNV systems (PAPR nested API v1).
>
> For nested API v2 (PowerVM), compatibility capabilities are obtained
> from the hypervisor via the H_GUEST_GET_CAPABILITIES hcall. This
> information is not available on PowerNV systems.
>
> For nested API v1, derive the compatibility capabilities from the L1
> guest by reading the "cpu-version" property from the device tree, which
> reflects the effective (logical) processor compatibility level. Map this
> value to the corresponding compatibility capability bitmap.
>
> Introduce a helper to translate CPU version values into compatibility
> capability bits and integrate it into kvmppc_get_compat_cpu_caps().
>
> This allows userspace to query host CPU compatibility modes on both
> PowerVM and PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS ioctl.
>
> Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 37 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 38de7040e2b7..18774c49af85 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6522,15 +6522,50 @@ static bool kvmppc_hash_v3_possible(void)
> return true;
> }
>
> +static int kvmppc_map_compat_capabilities(const __be32 cpu_version,
> + unsigned long *capabilities)
> +{
> + switch (cpu_version) {
> + case PVR_ARCH_31_P11:
> + *capabilities |= H_GUEST_CAP_POWER11;
> + break;
> + case PVR_ARCH_31:
> + *capabilities |= H_GUEST_CAP_POWER10;
> + break;
> + case PVR_ARCH_300:
> + *capabilities |= H_GUEST_CAP_POWER9;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
>
> static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> {
> + struct device_node *np;
> unsigned long capabilities = 0;
> + const __be32 *prop = NULL;
> long rc = -EINVAL;
> + u32 cpu_version;
>
> if (kvmhv_on_pseries()) {
> - if (kvmhv_is_nestedv2())
> + if (kvmhv_is_nestedv2()) {
> rc = plpar_guest_get_capabilities(0,
> &capabilities);
Need to mask capabilities as mentioned in the review comments for
previous patch. I would suggest creating a helper that performs the
hcall and applies the mask which can then be used at
plpar_guest_get_capabilities() call sites.
> + } else {
> + for_each_node_by_type(np, "cpu") {
> + prop = of_get_property(np, "cpu-version", NULL);
> + if (prop) {
> + cpu_version = be32_to_cpup(prop);
> + break;
> + }
> + }
> + if (!prop)
> + return -EINVAL;
> + rc = kvmppc_map_compat_capabilities(cpu_version,
> + &capabilities);
> + }
> host_caps->compat_capabilities = capabilities;
> }
>
> --
> 2.50.1 (Apple Git-155)
>
--
Cheers
~ Vaibhav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox