On 2026/05/05 02:55 PM, Harsh Prateek Bora wrote:
>
>
> On 30/04/26 11:19 am, Amit Machhiwal wrote:
> > 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.
> >
> > Signed-off-by: Amit Machhiwal <[email protected]>
> > ---
> > arch/powerpc/kvm/book3s_hv.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index 948c6b099a29..d602d90111d1 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -6516,6 +6516,22 @@ 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())
>
> If this is only intended for nested APIv2, it should reflect in commit
> log/title, otherwise, we need to return success with capabilities set to 0
> for non-nestedv2 case.
This patch is specific to nested API v2. I tried to convey that through the “KVM
on PowerVM” in the commit title, and I also described the API v2 scope in the
commit log. If that is still not explicit enough, I can update the title and
commit log in the next revision to make the limitation clearer.
>
> Also, better to have combined check for pseries and nestedv2 if we are not
> handling other cases.
We are, in the next patch.
>
> > + rc = plpar_guest_get_capabilities(0, &capabilities);
> > + host_caps->compat_capabilities = capabilities;
>
> Do we need to take care of PowerNV case ?
Next patch takes care of it.
Thanks,
Amit
> > + }
> > +
> > + 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,
> > @@ -6558,6 +6574,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)
>
