* Re: [PATCH v4] powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM
From: Harsh Prateek Bora @ 2026-06-02 17:11 UTC (permalink / raw)
To: Gautam Menghani, maddy, mpe, npiggin, chleroy
Cc: linuxppc-dev, linux-kernel, stable, Sean Christopherson
In-Reply-To: <20260602121706.8423-1-gautam@linux.ibm.com>
On 02/06/26 5:47 pm, Gautam Menghani wrote:
> Currently, CONFIG_VPA_PMU is not enabled by default, and consequently
> cannot be used for KVM guests at all, unless explicitly enabled on
> host kernel.
>
> Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is
> being used.
>
> Fixes: 176cda0619b6c ("powerpc/perf: Add perf interface to expose vpa counters")
> Cc: stable@vger.kernel.org # v6.13+
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> ---
> v3 -> v4:
> 1. Reword the patch description (Harsh)
>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
> v2 -> v3:
> 1. Make CONFIG_VPA_PMU as default m so that it can separately disabled
> (Sean)
>
> v1 -> v2:
> 1. Rebased on latest master
>
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index f7052b131a4c..74910ce3a541 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -154,6 +154,7 @@ config HV_PERF_CTRS
> config VPA_PMU
> tristate "VPA PMU events"
> depends on KVM_BOOK3S_64_HV && HV_PERF_CTRS
> + default m
> help
> Enable access to the VPA PMU counters via perf. This enables
> code that support measurement for KVM on PowerVM(KoP) feature.
^ permalink raw reply
* Re: [PATCH v2] perf kvm stat: Add missing mappings for PPC kvm exit reasons
From: Amit Machhiwal @ 2026-06-02 18:52 UTC (permalink / raw)
To: Gautam Menghani
Cc: peterz, mingo, acme, namhyung, mark.rutland, alexander.shishkin,
jolsa, irogers, adrian.hunter, james.clark, atrajeev,
linuxppc-dev, linux-perf-users, linux-kernel
In-Reply-To: <20260518125041.39286-1-gautam@linux.ibm.com>
On 2026/05/18 06:20 PM, Gautam Menghani wrote:
> The macro kvm_trace_symbol_exit is used for providing the mappings
> for the exit trap vectors and their names. Add mappings for H_FAC_UNAVAIL
> and H_VIRT so that exit reasons are displayed as string instead of
> vector numbers when using perf kvm stat.
Do we want to make a copy of the existing header in perf to keep things in sync
with check-headers.sh as suggested by Ian earlier?
Thanks,
Amit
>
> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> ---
> v1 -> v2:
> 1. Update the patch title and description to remove dependency on
> another file trace_book3s.h
>
> tools/perf/util/kvm-stat-arch/book3s_hv_exits.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/kvm-stat-arch/book3s_hv_exits.h b/tools/perf/util/kvm-stat-arch/book3s_hv_exits.h
> index 2011376c7ab5..2688ca7d0399 100644
> --- a/tools/perf/util/kvm-stat-arch/book3s_hv_exits.h
> +++ b/tools/perf/util/kvm-stat-arch/book3s_hv_exits.h
> @@ -26,8 +26,10 @@
> {0xe00, "H_DATA_STORAGE"}, \
> {0xe20, "H_INST_STORAGE"}, \
> {0xe40, "H_EMUL_ASSIST"}, \
> + {0xea0, "H_VIRT"}, \
> {0xf00, "PERFMON"}, \
> {0xf20, "ALTIVEC"}, \
> - {0xf40, "VSX"}
> + {0xf40, "VSX"}, \
> + {0xf80, "H_FAC_UNAVAIL"}
>
> #endif
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v4] powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM
From: Amit Machhiwal @ 2026-06-02 19:04 UTC (permalink / raw)
To: Gautam Menghani
Cc: maddy, mpe, npiggin, chleroy, linuxppc-dev, linux-kernel, harshpb,
stable, Sean Christopherson
In-Reply-To: <20260602121706.8423-1-gautam@linux.ibm.com>
On 2026/06/02 05:47 PM, Gautam Menghani wrote:
> Currently, CONFIG_VPA_PMU is not enabled by default, and consequently
> cannot be used for KVM guests at all, unless explicitly enabled on
> host kernel.
>
> Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is
> being used.
>
> Fixes: 176cda0619b6c ("powerpc/perf: Add perf interface to expose vpa counters")
> Cc: stable@vger.kernel.org # v6.13+
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> ---
> v3 -> v4:
> 1. Reword the patch description (Harsh)
>
> v2 -> v3:
> 1. Make CONFIG_VPA_PMU as default m so that it can separately disabled
> (Sean)
>
> v1 -> v2:
> 1. Rebased on latest master
>
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index f7052b131a4c..74910ce3a541 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -154,6 +154,7 @@ config HV_PERF_CTRS
> config VPA_PMU
> tristate "VPA PMU events"
> depends on KVM_BOOK3S_64_HV && HV_PERF_CTRS
> + default m
LGTM.
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss
From: Will Deacon @ 2026-06-02 20:34 UTC (permalink / raw)
To: linux-arm-kernel, Ard Biesheuvel
Cc: catalin.marinas, kernel-team, Will Deacon, linux-kernel,
mark.rutland, Ard Biesheuvel, 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
In-Reply-To: <20260529150150.1670604-17-ardb+git@google.com>
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.
Applied to arm64 (for-next/mm), thanks!
[01/15] arm64: mm: Remove bogus stop condition from map_mem() loop
https://git.kernel.org/arm64/c/36ca7f4be809
[02/15] arm64: mm: Drop redundant pgd_t* argument from map_mem()
https://git.kernel.org/arm64/c/2e527667a3b9
[03/15] arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings
https://git.kernel.org/arm64/c/8dd640d9233d
[04/15] arm64: mm: Preserve existing table mappings when mapping DRAM
https://git.kernel.org/arm64/c/a64293e993f6
[05/15] arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
https://git.kernel.org/arm64/c/ecda73ae92ca
[06/15] arm64: mm: Permit contiguous descriptors to be manipulated
https://git.kernel.org/arm64/c/05c5c31e9d8d
[07/15] arm64: kfence: Avoid NOMAP tricks when mapping the early pool
https://git.kernel.org/arm64/c/dfd73e574d38
[08/15] arm64: mm: Permit contiguous attribute for preliminary mappings
https://git.kernel.org/arm64/c/28becb2c1d74
[09/15] arm64: Move fixmap and kasan page tables to end of kernel image
https://git.kernel.org/arm64/c/382a03e12eba
[10/15] arm64: mm: Don't abuse memblock NOMAP to check for overlaps
https://git.kernel.org/arm64/c/d672a4b72c95
[11/15] powerpc/code-patching: Avoid r/w mapping of the zero page
https://git.kernel.org/arm64/c/c0693153fb17
[12/15] sh: Drop cache flush of the zero page at boot
https://git.kernel.org/arm64/c/99bad3e992e2
[13/15] mm: Make empty_zero_page[] const
https://git.kernel.org/arm64/c/0aae825f1ed7
[14/15] arm64: mm: Map the kernel data/bss read-only in the linear map
https://git.kernel.org/arm64/c/f2ba877402e5
[15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
https://git.kernel.org/arm64/c/63e0b6a5b693
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 07/14] pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO
From: Timur Tabi @ 2026-06-02 20:50 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Catalin Marinas, Will Deacon, Alexey Brodkin, Vineet Gupta,
Scott Wood, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Dvorkin Dmitry, Wells Lu,
Lee Jones, Pavel Machek, Guenter Roeck, Wim Van Sebroeck,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Sebastian Reichel,
linux-arm-kernel, linux-kernel, linux-snps-arc, linuxppc-dev,
netdev, linux-gpio, linux-amlogic, linux-leds, linux-hwmon,
linux-watchdog, linux-media, linux-staging, linux-pm
In-Reply-To: <20260304-gpio-of-kconfig-v1-7-d597916e79e7@oss.qualcomm.com>
On Wed, Mar 4, 2026 at 3:07 AM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> @@ -557,7 +549,6 @@ config PINCTRL_ST
> config PINCTRL_STMFX
> tristate "STMicroelectronics STMFX GPIO expander pinctrl driver"
> depends on I2C
> - depends on OF_GPIO
> depends on HAS_IOMEM
> select GENERIC_PINCONF
> select GPIOLIB_IRQCHIP
This change causes the following warning on builds:
WARNING: unmet direct dependencies detected for MFD_STMFX
Depends on [n]: HAS_IOMEM [=y] && I2C [=y] && OF [=n]
Selected by [m]:
- PINCTRL_STMFX [=m] && PINCTRL [=y] && I2C [=y] && HAS_IOMEM [=y]
WARNING: unmet direct dependencies detected for MFD_STMFX
Depends on [n]: HAS_IOMEM [=y] && I2C [=y] && OF [=n]
Selected by [m]:
- PINCTRL_STMFX [=m] && PINCTRL [=y] && I2C [=y] && HAS_IOMEM [=y]
I believe the proper fix is to have PINCTRL_STMFX depend on CONFIG_OF,
since this driver actually does depend on CONFIG_OF. The warning
comes because if CONFIG_OF is disabled, PINCTRL_STMFX can still be
enabled, but in doing so it selects MFD_STMFX which does depend on
CONFIG_OF.
Adding "depends on OF" to "config PINCTRL_STMFX" seems to fix the
problem, but I'm not familiar with this driver so I'm not sure this is
the right fix. I'll post a patch.
^ permalink raw reply
* Re: [PATCH] smp: prevent soft lockup in smp_call_function_many_cond
From: Chris Packham @ 2026-06-02 21:18 UTC (permalink / raw)
To: Mark Tomlinson, Madhavan Srinivasan, Thomas Gleixner,
yury.norov@gmail.com, paulmck@kernel.org,
romank@linux.microsoft.com, rafael.j.wysocki@intel.com,
riel@surriel.com, joelagnelf@nvidia.com
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20260527031618.2940365-1-mark.tomlinson@alliedtelesis.co.nz>
(adding others suggested by get_maintainer.pl)
On 27/05/2026 15:16, Mark Tomlinson wrote:
> Using the PowerPC P2040 (e500mc) CPU, soft lockups can occasionally be
> seen in smp_call_function_many_cond(). The conclusion is that this CPU
> does not process the doorbell interrupt while in a data-storage (MMU)
> exception. If more than one CPU in a multi core environment is calling
> this function at the same time, it is possible for a deadlock to occur.
>
> The fix for this is to call flush_smp_call_function_queue() before
> waiting for responses from other CPUs. If there is something in the
> queue, this is a good time to process it before busy-waiting on other
> CPUs. On other architectures this call will quickly do nothing, as the
> queue will be empty.
>
> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
> ---
> kernel/smp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index a0bb56bd8dda..3c4467654ab0 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -884,6 +884,8 @@ static void smp_call_function_many_cond(const struct cpumask *mask,
> local_irq_restore(flags);
> }
>
> + flush_smp_call_function_queue();
> +
> if (run_remote && wait) {
> for_each_cpu(cpu, cfd->cpumask) {
> call_single_data_t *csd;
^ permalink raw reply
* Re: [PATCH 06/23] driver core: platform: provide platform_device_set_of_node()
From: Andy Shevchenko @ 2026-06-02 21:40 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-6-88c324a1b8d2@oss.qualcomm.com>
On Thu, May 21, 2026 at 10:36:29AM +0200, Bartosz Golaszewski wrote:
> Encapsulate the reference counting logic for OF nodes assigned to
> platform devices created with platform_device_alloc() in a helper
> function. Make the kerneldoc state that this is the proper interface for
> assigning OF nodes to dynamically allocated platform devices. This will
> allow us to switch to counting the references of the device's firmware
> nodes, not only the OF nodes.
...
> +/**
> + * platform_device_set_of_node - assign an OF node to device
> + * @pdev: platform device to add the node for
> + * @np: new device node
> + *
> + * Assign an OF node to this platform device. Internally keep track of the
> + * reference count. Devices created with platform_device_alloc() must use this
> + * function instead of assigning the node manually.
> + */
> +void platform_device_set_of_node(struct platform_device *pdev,
> + struct device_node *np)
Why not fwnode to begin with?
> +{
> + of_node_put(pdev->dev.of_node);
And if it has an fwnode?
> + pdev->dev.of_node = of_node_get(np);
> + pdev->dev.fwnode = of_fwnode_handle(np);
This looks like
device_set_node(&pdev->dev, fwnode_handle_get(...));
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 07/23] driver core: platform: provide platform_device_set_fwnode()
From: Andy Shevchenko @ 2026-06-02 21:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-7-88c324a1b8d2@oss.qualcomm.com>
On Thu, May 21, 2026 at 10:36:30AM +0200, Bartosz Golaszewski wrote:
> Provide a helper function encapsulating the logic of assigning firmware
> nodes to platform devices created with platform_device_alloc(). Make the
> kerneldoc state that this is the proper interface for assigning firmware
> nodes to dynamically allocated platform devices. This will allow us to
> switch to counting the references of the device's firmware nodes in the
> future, not only the OF nodes.
But why different for of_node and fwnode to begin with?!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 08/23] driver core: platform: provide platform_device_set_of_node_from_dev()
From: Andy Shevchenko @ 2026-06-02 21:44 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-8-88c324a1b8d2@oss.qualcomm.com>
On Thu, May 21, 2026 at 10:36:31AM +0200, Bartosz Golaszewski wrote:
> Provide a platform-specific variant of device_set_of_node_from_dev(). In
> addition to bumping the reference count of the OF node being assigned,
> it also assigns the fwnode of the platform device.
Can we rather investigate the way how to make that of node reuse thingy
(which is used solely by pin control) differently and then drop this confusing
device_set_of_node_from_dev() call altogether?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 20/23] usb: chipidea: use platform_device_set_of_node_from_dev()
From: Andy Shevchenko @ 2026-06-02 21:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-20-88c324a1b8d2@oss.qualcomm.com>
On Thu, May 21, 2026 at 10:36:43AM +0200, Bartosz Golaszewski wrote:
> Ahead of reworking the reference counting logic for platform devices,
> encapsulate the assignment of the OF node from another device for
> dynamically allocated platform devices with the provided helper.
...
> pdev->dev.parent = dev;
> - device_set_of_node_from_dev(&pdev->dev, dev);
> + platform_device_set_of_node_from_dev(pdev, dev);
Why do they even do that? Do they have a USB connected pin control?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 21/23] usb: musb: use platform_device_set_of_node_from_dev()
From: Andy Shevchenko @ 2026-06-02 21:50 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-21-88c324a1b8d2@oss.qualcomm.com>
On Thu, May 21, 2026 at 10:36:44AM +0200, Bartosz Golaszewski wrote:
> Ahead of reworking the reference counting logic for platform devices,
> encapsulate the assignment of the OF node from another device for
> dynamically allocated platform devices with the provided helper.
Same Q as per chipidea. Do they provide a pin control facility at the same time?
Otherwise simple device_set_node() or whatever platform analogue should suffice.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 22/23] reset: rzg2l: use platform_device_set_of_node_from_dev()
From: Andy Shevchenko @ 2026-06-02 21:52 UTC (permalink / raw)
To: Philipp Zabel
Cc: Bartosz Golaszewski, Lee Jones, Mark Brown, Thierry Reding,
Sebastian Hesselbarth, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Srinivas Kandagatla,
Greg Kroah-Hartman, Vinod Koul, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Maximilian Luz,
Hans de Goede, Ilpo Järvinen, Krzysztof Kozlowski,
Benjamin Herrenschmidt, brgl, linux-kernel, netdev, linux-arm-msm,
linux-sound, driver-core, devicetree, linuxppc-dev, linux-i2c,
iommu, linux-pm, imx, linux-arm-kernel, intel-xe, dri-devel,
linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <6af284545729f03a60d06479339862a2f08c6b7e.camel@pengutronix.de>
On Tue, Jun 02, 2026 at 10:24:41AM +0200, Philipp Zabel wrote:
> On Do, 2026-05-21 at 10:36 +0200, Bartosz Golaszewski wrote:
> > Ahead of reworking the reference counting logic for platform devices,
> > encapsulate the assignment of the OF node from another device for
> > dynamically allocated platform devices with the provided helper.
...
> > - device_set_of_node_from_dev(&vdev->dev, dev);
> > + platform_device_set_of_node_from_dev(vdev, dev);
Same Q here, why it uses inherited call? Cargo cult?
'reused' flag is solely pin control (provider!) thingy as far as I remember.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-03 0:54 UTC (permalink / raw)
To: Michael Kelley
Cc: Aneesh Kumar K.V, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <SN6PR02MB4157D9955A93244014AB7978D4122@SN6PR02MB4157.namprd02.prod.outlook.com>
On Tue, Jun 02, 2026 at 02:24:40PM +0000, Michael Kelley wrote:
> Except that in a normal VM, the "unencrypted" pool attribute does *not*
> describe the state of the memory itself. In a normal VM, the memory is
> unencrypted, but the "unencrypted" pool attribute is false. That
> contradiction is the essence of my concern.
I would argue no..
When CC is enabled the default state of memory in a Linux environment
is "encrypted". You have to take a special action to "decrypt" it.
Thus the default state of memory in a non-CC environment is also
paradoxically "encrypted" too. "decryption" is impossible.
Therefore the "unencrypted" state is a special state that only memory
inside a CC VM can have. A normal VM can never have "unencrypted"
memory at all, so having it be false in the pool is accurate as far as
the APIs go.
un-encrypted = true means "the memory in this pool was transformed with
set_memory_decrypted()" - which is impossible on a normal VM.
Jason
^ permalink raw reply
* [PATCH] i2c: cpm: Use platform_get_irq() to retrieve interrupt
From: Rosen Penev @ 2026-06-03 0:54 UTC (permalink / raw)
To: linux-i2c
Cc: Jochen Friedrich, Andi Shyti, open list:FREESCALE I2C CPM DRIVER,
open list
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.
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",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] smp: prevent soft lockup in smp_call_function_many_cond
From: Rik van Riel @ 2026-06-03 1:37 UTC (permalink / raw)
To: Mark Tomlinson, Madhavan Srinivasan, Thomas Gleixner
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <20260527031618.2940365-1-mark.tomlinson@alliedtelesis.co.nz>
On Wed, 2026-05-27 at 15:16 +1200, Mark Tomlinson wrote:
> Using the PowerPC P2040 (e500mc) CPU, soft lockups can occasionally
> be
> seen in smp_call_function_many_cond(). The conclusion is that this
> CPU
> does not process the doorbell interrupt while in a data-storage (MMU)
> exception. If more than one CPU in a multi core environment is
> calling
> this function at the same time, it is possible for a deadlock to
> occur.
Does that mean if the CPU in question does not call
smp_call_function_many_cond() while in a data-storage
exception, the system might still hang?
Not that there's anything wrong with reducing the
frequency of what is (presumably) an already pretty
rare hang.
>
> The fix for this is to call flush_smp_call_function_queue() before
> waiting for responses from other CPUs. If there is something in the
> queue, this is a good time to process it before busy-waiting on other
> CPUs. On other architectures this call will quickly do nothing, as
> the
> queue will be empty.
Agreed, this does look completely harmless at worst,
and does look like it would at the very least improve
that e500mc issue.
>
> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
>
Reviewed-by: Rik van Riel <riel@surriel.com>
--
All Rights Reversed.
^ permalink raw reply
* Re: [PATCH v3 19/19] mm/mm_init: Fold __init_page_from_nid() into __init_deferred_page()
From: Muchun Song @ 2026-06-03 2:39 UTC (permalink / raw)
To: Mike Rapoport
Cc: Muchun Song, Oscar Salvador, David Hildenbrand, Andrew Morton,
Madhavan Srinivasan, Michael Ellerman, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, linux-mm, linux-kernel,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Ritesh Harjani (IBM), Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <178041489408.457517.2991925440539441241.b4-review@b4>
> On Jun 2, 2026, at 23:41, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, 02 Jun 2026 18:10:39 +0800, Muchun Song <songmuchun@bytedance.com> wrote:
>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>> index 41b83dd18c01..f1bbf3b9a321 100644
>> --- a/mm/mm_init.c
>> +++ b/mm/mm_init.c
>> @@ -771,10 +746,27 @@ defer_init(int nid, unsigned long pfn, unsigned long end_pfn)
>>
>> static void __meminit __init_deferred_page(unsigned long pfn, int nid)
>> {
>> + pg_data_t *pgdat;
>> + int zid;
>> +
>> if (early_page_initialised(pfn, nid))
>> return;
>>
>> - __init_page_from_nid(pfn, nid);
>> + pgdat = NODE_DATA(nid);
>
> Nit: we can initialize pgdat at declaration line, other than that
Yes, will do next version.
>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Thanks.
>
> --
> Sincerely yours,
> Mike.
>
^ permalink raw reply
* Re: [PATCH v3 18/19] mm/hugetlb: Remove unused bootmem cma field
From: Muchun Song @ 2026-06-03 2:41 UTC (permalink / raw)
To: Mike Rapoport
Cc: Muchun Song, Oscar Salvador, David Hildenbrand, Andrew Morton,
Madhavan Srinivasan, Michael Ellerman, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, linux-mm, linux-kernel,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Ritesh Harjani (IBM), Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <178041489401.457517.7510742037477989122.b4-review@b4>
> On Jun 2, 2026, at 23:41, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, 02 Jun 2026 18:10:38 +0800, Muchun Song <songmuchun@bytedance.com> wrote:
>> struct huge_bootmem_page no longer needs to keep the CMA pointer. The
>> bootmem path only needs to remember whether a huge page came from CMA,
>> which is already encoded in the flags field.
>>
>> Set HUGE_BOOTMEM_CMA when the page is allocated and drop the unused cma
>> field together with the redundant assignments.
>
> It looks like the commit does more refactoring, please mention it in the
> changelog.
Will do.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 15/19] mm/hugetlb_vmemmap: Move bootmem HVO setup to early init
From: Muchun Song @ 2026-06-03 2:42 UTC (permalink / raw)
To: Mike Rapoport
Cc: Muchun Song, Oscar Salvador, David Hildenbrand, Andrew Morton,
Madhavan Srinivasan, Michael Ellerman, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, linux-mm, linux-kernel,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Ritesh Harjani (IBM), Aneesh Kumar K.V, linuxppc-dev,
Mike Kravetz
In-Reply-To: <178041489396.457517.6730523256790632908.b4-review@b4>
> On Jun 2, 2026, at 23:41, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, 02 Jun 2026 18:10:35 +0800, Muchun Song <songmuchun@bytedance.com> wrote:
>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>> index ea6af85bfec1..464578ee246e 100644
>> --- a/mm/hugetlb_vmemmap.c
>> +++ b/mm/hugetlb_vmemmap.c
>> @@ -745,6 +745,8 @@ static bool vmemmap_should_optimize_bootmem_page(struct huge_bootmem_page *m)
>> return true;
>> }
>>
>> +static struct zone *pfn_to_zone(unsigned nid, unsigned long pfn);
>> +
>
> Can we please move the entire function rather than add a forward
> declaration?
Yes. Will update next version.
>
> Other than that
>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Thanks.
>
> --
> Sincerely yours,
> Mike.
>
^ permalink raw reply
* Re: [PATCH v3 14/19] mm/hugetlb: Free cross-zone bootmem gigantic pages after allocation
From: Muchun Song @ 2026-06-03 2:53 UTC (permalink / raw)
To: Mike Rapoport
Cc: Muchun Song, Oscar Salvador, David Hildenbrand, Andrew Morton,
Madhavan Srinivasan, Michael Ellerman, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, linux-mm, linux-kernel,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Ritesh Harjani (IBM), Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <178041489395.457517.12727427621570734471.b4-review@b4>
> On Jun 2, 2026, at 23:41, Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, 02 Jun 2026 18:10:34 +0800, Muchun Song <songmuchun@bytedance.com> wrote:
>
> Hi Muchun,
Hi Mike,
>
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 5e557c05d80a..218fb1ca45f4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3073,22 +3076,38 @@ static bool __init alloc_bootmem_huge_page(struct hstate *h, int nid)
>> [ ... skip 26 lines ... ]
>> + * pages belonging to the requested node.
>> + */
>> + if (WARN_ON_ONCE(nid_request != NUMA_NO_NODE && nid != nid_request))
>> + list_add(&m->list, &huge_boot_pages[nid_request]);
>> + else
>> + list_add(&m->list, &huge_boot_pages[nid]);
>
> Can we just memblock_free() the page that intersects zones here?
I had previously considered doing this, but then I realized that if we free the
allocated cross-zone memory here, memblock is very likely to select the exact
same block for the next allocation. This means we'd just end up with this
cross-zone memory again, degrading allocation efficiency. Unless there is a way
to mark the block so memblock avoids reallocating it, I ultimately chose to
defer the release to prevent this issue from happening.
Thanks.
>
> Rather than making alloc_bootmem_huge_page() bool (sorry my bad :)) we
> can make it return -ENOMEM when memblock_alloc() fails, 0 if the page is
> not usable and 1 (i.e. number of allocated gigantic pages) if everything
> is fine.
>
> The callers would need a bit of massage, but it still seems simpler to
> me than adding them to the list and then walking that list.
>
> --
> Sincerely yours,
> Mike.
>
^ permalink raw reply
* Re: [PATCH v3 1/5] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
From: Vaibhav Jain @ 2026-06-03 3:33 UTC (permalink / raw)
To: Ritesh Harjani, Amit Machhiwal
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan,
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: <cxyewhx8.ritesh.list@gmail.com>
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
> 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
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH v3 2/5] KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl
From: Vaibhav Jain @ 2026-06-03 3:46 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-3-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for this patch. Few review comments below:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> Introduce a new capability and ioctl to expose CPU compatibility modes
> supported by the host processor for nested guests.
>
> On IBM POWER systems, newer processor generations (N) can operate in
> compatibility modes corresponding to earlier generations, like (N-1) and
> (N-2). This is particularly relevant for nested virtualization, where
> nested KVM guests may need to run with a specific processor compatibility
> level.
>
> Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
> KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
> the compatibility modes supported by the host in respective bit numbers,
> allowing userspace (e.g., QEMU) to select an appropriate compatibility
> level when configuring nested KVM guests.
>
> The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
> CPU compatibility capabilities via a PowerPC-specific backend
> implementation when available. If the capability is not supported, the
> ioctl returns success with no capabilities set, allowing userspace to
> fall back gracefully.
>
> 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/include/asm/kvm_ppc.h | 1 +
> arch/powerpc/include/uapi/asm/kvm.h | 6 ++++++
> arch/powerpc/kvm/powerpc.c | 21 +++++++++++++++++++++
> include/uapi/linux/kvm.h | 4 ++++
> 4 files changed, 32 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 0953f2daa466..cadfb839e836 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -319,6 +319,7 @@ struct kvmppc_ops {
> bool (*hash_v3_possible)(void);
> int (*create_vm_debugfs)(struct kvm *kvm);
> int (*create_vcpu_debugfs)(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
> + int (*get_compat_cpu_ver)(struct kvm_ppc_compat_caps *host_caps);
> };
>
> extern struct kvmppc_ops *kvmppc_hv_ops;
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 077c5437f521..081d6c7f7f70 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -437,6 +437,12 @@ struct kvm_ppc_cpu_char {
> __u64 behaviour_mask; /* valid bits in behaviour */
> };
>
> +/* For KVM_PPC_GET_COMPAT_CAPS */
> +struct kvm_ppc_compat_caps {
> + __u64 flags; /* Reserved for future use */
Please introduce a size field also for the UAPI so that in this
structure can evolve in future without breaking kernel ABI.
> + __u64 compat_capabilities; /* Capabilities supported by the host */
> +};
> +
> /*
> * Values for character and character_mask.
> * These are identical to the values used by H_GET_CPU_CHARACTERISTICS.
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 00302399fc37..02b834ebd8d3 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -697,6 +697,13 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> }
> }
> break;
> +#if defined(CONFIG_KVM_BOOK3S_HV_POSSIBLE)
> + case KVM_CAP_PPC_COMPAT_CAPS:
> + r = 0;
> + if (kvmhv_on_pseries())
> + r = 1;
> + break;
> +#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> default:
> r = 0;
> break;
> @@ -2463,6 +2470,20 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> r = kvm->arch.kvm_ops->svm_off(kvm);
> break;
> }
> + case KVM_PPC_GET_COMPAT_CAPS: {
> + struct kvm_ppc_compat_caps host_caps;
> +
> + r = -ENOTTY;
> + memset(&host_caps, 0, sizeof(host_caps));
> + if (!kvm->arch.kvm_ops->get_compat_cpu_ver)
> + goto out;
> +
> + r = kvm->arch.kvm_ops->get_compat_cpu_ver(&host_caps);
> + if (!r && copy_to_user(argp, &host_caps,
> + sizeof(host_caps)))
As mentioned above please introduce a size field in the structure thats
being copied to the userspace and use the size field to copy the
apporiate structure to the userspace. Otherwise a future kernel may
unintentionally overwrite unintended userspace memory if it happens to
be using a larger structure size then what VMM knows about.
> + r = -EFAULT;
> + break;
> + }
> default: {
> struct kvm *kvm = filp->private_data;
> r = kvm->arch.kvm_ops->arch_vm_ioctl(filp, ioctl, arg);
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 6c8afa2047bf..1788a0068662 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
> #define KVM_CAP_S390_USER_OPEREXEC 246
> #define KVM_CAP_S390_KEYOP 247
> #define KVM_CAP_S390_VSIE_ESAMODE 248
> +#define KVM_CAP_PPC_COMPAT_CAPS 249
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1349,6 +1350,9 @@ struct kvm_s390_keyop {
> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr)
> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct kvm_device_attr)
>
> +/* Available with KVM_CAP_PPC_COMPAT_CAPS */
> +#define KVM_PPC_GET_COMPAT_CAPS _IOR(KVMIO, 0xe4, struct
> kvm_ppc_compat_caps)
Minor: you may want to align the name of the newly introduced kvmppc_ops
to KVM CAP you are introducing here.
> +
> /*
> * ioctls for vcpu fds
> */
> --
> 2.50.1 (Apple Git-155)
>
>
--
Cheers
~ Vaibhav
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Cache OPAL check_token() results
From: Sourabh Jain @ 2026-06-03 3:52 UTC (permalink / raw)
To: Shivang Upadhyay, linuxppc-dev, linux-kernel
Cc: maddy, mpe, npiggin, chleroy, thuth, Aditya Gupta,
Mahesh J Salgaonkar
In-Reply-To: <20260601112520.161605-1-shivangu@linux.ibm.com>
On 01/06/26 16:55, Shivang Upadhyay wrote:
> Add a caching layer for the opal_check_token() OPAL call to avoid
> repeated firmware calls for token availability checks.
>
> The opal_check_token() function is used to determine if a specific
> OPAL firmware call is supported on the current platform. This check
> is performed frequently during boot and runtime, resulting in
> unnecessary firmware calls for the same token values.
>
> This reduces firmware call overhead during boot and runtime token
> checks while maintaining compatibility with existing code.
>
> Testing with buildroot images shows OPAL calls reduced from
> 35578 to 28983, before console bring-up.
Yes, it is a good idea to avoid making repetitive calls to check whether
an OPAL call is supported by the firmware.
But it feels like it would have been better if skiboot itself advertised
support for OPAL calls via the FDT, similar to how RTAS does.
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <chleroy@kernel.org>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Mahesh J Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
> ---
> arch/powerpc/include/asm/opal.h | 1 +
> arch/powerpc/platforms/powernv/opal-call.c | 2 +-
> arch/powerpc/platforms/powernv/opal.c | 55 ++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 0a398265ba04..e7e11479122b 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -156,6 +156,7 @@ int64_t opal_pci_next_error(uint64_t phb_id, __be64 *first_frozen_pe,
> int64_t opal_pci_poll(uint64_t id);
> int64_t opal_return_cpu(void);
> int64_t opal_check_token(uint64_t token);
> +int64_t opal_check_token_call(uint64_t token);
> int64_t opal_reinit_cpus(uint64_t flags);
>
> int64_t opal_xscom_read(uint32_t gcid, uint64_t pcb_addr, __be64 *val);
> diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c
> index 021b0ec29e24..00325c189e69 100644
> --- a/arch/powerpc/platforms/powernv/opal-call.c
> +++ b/arch/powerpc/platforms/powernv/opal-call.c
> @@ -207,7 +207,7 @@ OPAL_CALL(opal_validate_flash, OPAL_FLASH_VALIDATE);
> OPAL_CALL(opal_manage_flash, OPAL_FLASH_MANAGE);
> OPAL_CALL(opal_update_flash, OPAL_FLASH_UPDATE);
> OPAL_CALL(opal_resync_timebase, OPAL_RESYNC_TIMEBASE);
> -OPAL_CALL(opal_check_token, OPAL_CHECK_TOKEN);
> +OPAL_CALL(opal_check_token_call, OPAL_CHECK_TOKEN);
> OPAL_CALL(opal_dump_init, OPAL_DUMP_INIT);
> OPAL_CALL(opal_dump_info, OPAL_DUMP_INFO);
> OPAL_CALL(opal_dump_info2, OPAL_DUMP_INFO2);
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index 1946dbdc9fa1..c32035136efa 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -73,6 +73,12 @@ static struct task_struct *kopald_tsk;
> static struct opal_msg *opal_msg;
> static u32 opal_msg_size __ro_after_init;
>
> +/* Token cache for opal_check_token() */
> +#define OPAL_TOKEN_CACHE_SIZE 256 /* Covers tokens 0-255, including OPAL_LAST (178) */
> +static unsigned long opal_token_cache[BITS_TO_LONGS(OPAL_TOKEN_CACHE_SIZE)] __ro_after_init;
> +static bool opal_token_cache_initialized __ro_after_init;
> +static void opal_token_cache_init(void);
> +
> void __init opal_configure_cores(void)
> {
> u64 reinit_flags = 0;
> @@ -1125,8 +1131,57 @@ EXPORT_SYMBOL_GPL(opal_flash_read);
> EXPORT_SYMBOL_GPL(opal_flash_write);
> EXPORT_SYMBOL_GPL(opal_flash_erase);
> EXPORT_SYMBOL_GPL(opal_prd_msg);
> +
> +/**
> + * opal_check_token - Check if an OPAL call token is supported
> + * @token: OPAL token number to check
> + *
> + * Returns 1 if supported, 0 if not.
> + * Uses a cached bitmap for fast lookups after initialization.
> + */
> +int64_t opal_check_token(uint64_t token)
> +{
> + /* Initialize if not done before */
> + if (!opal_token_cache_initialized) {
> + opal_token_cache_init();
> + }
> +
> + /* Use cached result */
> + if (token < OPAL_TOKEN_CACHE_SIZE) {
> + return test_bit(token, opal_token_cache);
> + }
> +
> + /* Fall back to direct OPAL call for out-of-range tokens */
> + return opal_check_token_call(token);
> +}
> EXPORT_SYMBOL_GPL(opal_check_token);
The current approach to finding supported OPAL calls is:
- Discover all supported OPAL calls during the first opal_check_token()
call.
- From the second call onward, check whether discovery has already been
done, and then test the token in opal_token_cache.
The approach looks reasonable, but how about doing it this way instead:
Maintain a tri-state value for each OPAL call:
0 - Status needs to be check
1 - Supported
-1 - Not supported
This would help in two ways:
1. No need to check opal_token_cache_initialized for every
opal_check_token() call
2. No need to discover support for all OPAL calls at once, it can be
done by need basis
With the tri-state approach, opal_check_token() could work like this:
1. Check the token status. If it is -1 or 1, return early.
2. Otherwise, query OPAL for support, update the status, and return
The only downside is that the array used to maintain OPAL call support
status would become slightly larger. 1 bit per opal call to 8 bit per
opal call.
>
> +/**
> + * opal_token_cache_init - Initialize the OPAL token cache
> + *
> + * Called during opal_init() to populate the token cache by querying
> + * OPAL firmware for all tokens in the supported range.
Seems like the above comment is not correct. I don't see below function
invoked from opal_init().
> + */
> +static void opal_token_cache_init(void)
> +{
> + uint64_t token;
> + int64_t result;
> +
> + pr_debug("Initializing OPAL token cache\n");
> +
> + /* Query OPAL for each token and cache the result */
> + for (token = 0; token < OPAL_TOKEN_CACHE_SIZE; token++) {
> + result = opal_check_token_call(token);
> + if (result == 1)
> + set_bit(token, opal_token_cache);
> + }
> +
> + /* Mark cache as initialized - enables fast path */
> + opal_token_cache_initialized = true;
> +
> + pr_info("OPAL token cache initialized\n");
> +}
> +
> /* Convert a region of vmalloc memory to an opal sg list */
> struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
> unsigned long vmalloc_size)
^ permalink raw reply
* Re: [PATCH] powerpc/prom: Remove redundant early_init_dt_scan_root() call
From: Sourabh Jain @ 2026-06-03 3:55 UTC (permalink / raw)
To: Shivang Upadhyay
Cc: linuxppc-dev, Aditya Gupta, Christophe Leroy (CS GROUP),
Hari Bathini, Madhavan Srinivasan, Mahesh Salgaonkar,
Michael Ellerman, Nicholas Piggin, Ritesh Harjani (IBM),
Venkat Rao Bagalkote, linux-kernel
In-Reply-To: <ah2KsuPcOu8tVOXo@shivang.upadyay>
On 01/06/26 19:10, Shivang Upadhyay wrote:
> On Sat, Apr 18, 2026 at 02:42:50PM +0530, Sourabh Jain wrote:
>> Commit 554b66233623 ("of/fdt: Scan the root node properties earlier")
>> moved the invocation of early_init_dt_scan_root() into
>> early_init_dt_verify().
>>
>> early_init_devtree() already calls early_init_dt_verify(), so the root
>> node properties are parsed before reaching the explicit call in this
>> function.
>>
>> Keeping the call here results in scanning the root node twice. Remove
>> the redundant call and rely on the invocation from
>> early_init_dt_verify().
>>
>> This change keeps the behavior the same and removes an unnecessary
>> duplicate call.
>>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Nicholas Piggin <npiggin@gmail.com>
>> Cc: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>> arch/powerpc/kernel/prom.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 9ed9dde7d231..d218c8cc1f73 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -824,7 +824,6 @@ void __init early_init_devtree(void *params)
>> fadump_append_bootargs();
>>
>> /* Scan memory nodes and rebuild MEMBLOCKs */
>> - early_init_dt_scan_root();
>> early_init_dt_scan_memory_ppc();
>>
>> /*
>> --
>> 2.52.0
>>
> Hi Sourabh,
>
> Patch Looks good to me. Ran a quick boot test also.
> Feel free to add.
>
> Tested-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Thanks for the testing and review, Shivang.
- Sourabh Jain
^ permalink raw reply
* Re: [PATCH v3 3/5] KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM
From: Vaibhav Jain @ 2026-06-03 4:01 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-4-amachhiw@linux.ibm.com>
Hi Amit,
Thanks for the patch. My review comments inline below:
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> On POWER systems, the host CPU may run in a compatibility mode (e.g., a
> Power11 processor operating in Power10 compatibility mode). In such
> cases, the effective CPU level exposed to guests differs from the
> physical processor generation.
>
> When running nested KVM guests, QEMU derives the host CPU type using
> mfpvr(), which reflects the physical processor version. This can result
> in a mismatch between the CPU model selected by QEMU and the
> compatibility mode enforced by the host, leading to guest boot failures.
>
> For example, booting a nested guest on a Power11 LPAR configured in
> Power10 compatibility mode fails with:
>
> KVM-NESTEDv2: couldn't set guest wide elements
> [..KVM reg dump..]
>
> This occurs because QEMU selects a CPU model corresponding to the
> physical processor (via mfpvr()), while the host operates in a lower
> compatibility mode. As a result, KVM rejects the requested compatibility
> level during guest initialization.
>
> Add support for retrieving host CPU compatibility capabilities for
> nested guests on PowerVM (PAPR nested API v2). The hypervisor provides
> the effective compatibility levels via the H_GUEST_GET_CAPABILITIES
> hcall, which reflects the processor modes negotiated between the Power
> hypervisor (L0) and the host partition (L1).
>
> On pseries systems, obtain the capability bitmap using
> plpar_guest_get_capabilities() and return it via struct
> kvm_ppc_compat_caps. This information is then exposed to userspace
> through the KVM_PPC_GET_COMPAT_CAPS ioctl.
>
> Hook the implementation into the Book3S HV kvmppc_ops so that it can be
> invoked by the generic KVM ioctl handling code.
>
> 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 | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 249d1f2e4e2c..38de7040e2b7 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6522,6 +6522,21 @@ static bool kvmppc_hash_v3_possible(void)
> return true;
> }
>
> +
> +static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> +{
> + unsigned long capabilities = 0;
> + long rc = -EINVAL;
> +
> + if (kvmhv_on_pseries()) {
> + if (kvmhv_is_nestedv2())
> + rc = plpar_guest_get_capabilities(0,
> &capabilities);
since this value will trikle back to userspace please apply a mask on
the hcall return value so that any reserved and non-PVR related bits
doesnt leak back to userspace.
> + host_caps->compat_capabilities = capabilities;
> + }
> +
> + return rc;
> +}
> +
> static struct kvmppc_ops kvm_ops_hv = {
> .get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
> .set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
> @@ -6564,6 +6579,7 @@ static struct kvmppc_ops kvm_ops_hv = {
> .hash_v3_possible = kvmppc_hash_v3_possible,
> .create_vcpu_debugfs = kvmppc_arch_create_vcpu_debugfs_hv,
> .create_vm_debugfs = kvmppc_arch_create_vm_debugfs_hv,
> + .get_compat_cpu_ver = kvmppc_get_compat_cpu_caps,
> };
>
> static int kvm_init_subcore_bitmap(void)
> --
> 2.50.1 (Apple Git-155)
>
>
--
Cheers
~ Vaibhav
^ 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