From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Amit Machhiwal <amachhiw@linux.ibm.com>
Cc: Amit Machhiwal <amachhiw@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Vaibhav Jain <vaibhav@linux.ibm.com>,
Anushree Mathur <anushree.mathur@linux.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Nicholas Piggin <npiggin@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Gautam Menghani <gautam@linux.ibm.com>
Subject: Re: [PATCH v7 3/4] KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV
Date: Fri, 07 Aug 2026 17:43:07 +0530 [thread overview]
Message-ID: <7bm2ku24.ritesh.list@gmail.com> (raw)
In-Reply-To: <20260807170704.3280f54c-e2-amachhiw@linux.ibm.com>
Amit Machhiwal <amachhiw@linux.ibm.com> writes:
> On 2026/08/07 10:24 AM, Ritesh Harjani wrote:
>> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>
> <snip>
>
>> >
>> > static int kvmppc_get_compat_caps(struct kvm_ppc_compat_caps *host_caps)
>> > {
>> > + struct device_node *np;
>> > unsigned long capabilities = 0;
>> > long rc = -EINVAL;
>> > + u32 cpu_version = 0;
>> >
>> > if (kvmhv_on_pseries()) {
>> > if (kvmhv_is_nestedv2()) {
>> > WARN_ON_ONCE(!nested_capabilities);
>> > capabilities = nested_capabilities;
>> > rc = 0;
>> > + } else {
>> > + for_each_node_by_type(np, "cpu") {
>> > + if (!of_property_read_u32(np, "cpu-version",
>> > + &cpu_version)) {
>> > + of_node_put(np);
>> > + break;
>> > + }
>> > + }
>>
>> What happens when we don't have "cpu-version" DT property?
>> Check this commit
>> 5a61ef74f269f2 ("powerpc/64s: Support new device tree binding for discovering CPU features")
>>
>> And also why do we need to parse the DT properties again?
>> Shouldn't we check something like this?
>>
>> if (cpu_has_feature(CPU_FTR_P11_PVR))
>> capabilities |= KVM_PPC_COMPAT_CAP_POWER11;
>> if (cpu_has_feature(CPU_FTR_ARCH_31))
>> capabilities |= KVM_PPC_COMPAT_CAP_POWER10;
>> if (cpu_has_feature(CPU_FTR_ARCH_300))
>> capabilities |= KVM_PPC_COMPAT_CAP_POWER9;
>>
>
> Thanks for the suggestion, Ritesh! After closer analysis, cpu_has_feature()
> would give the same result on pseries, but I believe that using 'cpu-version'
> directly is both more correct and more explicit for this context.
>
> Here's why:
>
> 1. 'ibm,powerpc-cpu-features' / dt-cpu-ftrs is baremetal (powernv/OPAL) only.
Arghh. That make sense. Thanks for checking.
The design with "cpu-version" sounds good in that case.
Please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
next prev parent reply other threads:[~2026-08-07 12:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 17:06 [PATCH v7 0/4] KVM: PPC: Expose CPU compatibility modes for nested guests Amit Machhiwal
2026-08-06 17:06 ` [PATCH v7 1/4] KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl Amit Machhiwal
2026-08-07 3:08 ` Ritesh Harjani
2026-08-07 10:55 ` Amit Machhiwal
2026-08-07 11:36 ` Ritesh Harjani
2026-08-07 12:15 ` Ritesh Harjani
2026-08-07 13:04 ` Amit Machhiwal
2026-08-06 17:06 ` [PATCH v7 2/4] KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM Amit Machhiwal
2026-08-07 4:31 ` Ritesh Harjani
2026-08-07 10:58 ` Amit Machhiwal
2026-08-06 17:06 ` [PATCH v7 3/4] KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV Amit Machhiwal
2026-08-07 4:54 ` Ritesh Harjani
2026-08-07 12:07 ` Amit Machhiwal
2026-08-07 12:13 ` Ritesh Harjani [this message]
2026-08-06 17:06 ` [PATCH v7 4/4] KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl Amit Machhiwal
2026-08-07 4:35 ` Ritesh Harjani
2026-08-07 13:36 ` Amit Machhiwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bm2ku24.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=amachhiw@linux.ibm.com \
--cc=anushree.mathur@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=corbet@lwn.net \
--cc=gautam@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=skhan@linuxfoundation.org \
--cc=vaibhav@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox