Message ID | 20240205181833.212955-1-amachhiw@linux.ibm.com |
---|---|
State | New |
Headers | show |
Series | [v3] KVM: PPC: Book3S HV: Fix L2 guest reboot failure due to empty 'arch_compat' | expand |
Hi Amit, One comment below ... Amit Machhiwal <amachhiw@linux.ibm.com> writes: > Currently, rebooting a pseries nested qemu-kvm guest (L2) results in > below error as L1 qemu sends PVR value 'arch_compat' == 0 via > ppc_set_compat ioctl. This triggers a condition failure in > kvmppc_set_arch_compat() resulting in an EINVAL. ... > > diff --git a/arch/powerpc/kvm/book3s_hv_nestedv2.c b/arch/powerpc/kvm/book3s_hv_nestedv2.c > index 5378eb40b162..6042bdc70230 100644 > --- a/arch/powerpc/kvm/book3s_hv_nestedv2.c > +++ b/arch/powerpc/kvm/book3s_hv_nestedv2.c > @@ -347,8 +348,26 @@ static int gs_msg_ops_vcpu_fill_info(struct kvmppc_gs_buff *gsb, > break; > } > case KVMPPC_GSID_LOGICAL_PVR: > - rc = kvmppc_gse_put_u32(gsb, iden, > - vcpu->arch.vcore->arch_compat); > + /* > + * Though 'arch_compat == 0' would mean the default > + * compatibility, arch_compat, being a Guest Wide > + * Element, cannot be filled with a value of 0 in GSB > + * as this would result into a kernel trap. > + * Hence, when `arch_compat == 0`, arch_compat should > + * default to L1's PVR. > + * > + * Rework this when PowerVM supports a value of 0 > + * for arch_compat for KVM API v2. > + */ Is there an actual plan that PowerVM will support this in future? If so, how will a future kernel know that it's running on a version of PowerVM that does support arch_compat == 0? Similarly how will we know when it's OK to drop support for this workaround? cheers
Hi Michael, Thanks for looking into the patch and your comments. On 2024/02/06 09:09 PM, Michael Ellerman wrote: > Hi Amit, > > One comment below ... > > Amit Machhiwal <amachhiw@linux.ibm.com> writes: > > Currently, rebooting a pseries nested qemu-kvm guest (L2) results in > > below error as L1 qemu sends PVR value 'arch_compat' == 0 via > > ppc_set_compat ioctl. This triggers a condition failure in > > kvmppc_set_arch_compat() resulting in an EINVAL. > ... > > > > diff --git a/arch/powerpc/kvm/book3s_hv_nestedv2.c b/arch/powerpc/kvm/book3s_hv_nestedv2.c > > index 5378eb40b162..6042bdc70230 100644 > > --- a/arch/powerpc/kvm/book3s_hv_nestedv2.c > > +++ b/arch/powerpc/kvm/book3s_hv_nestedv2.c > > @@ -347,8 +348,26 @@ static int gs_msg_ops_vcpu_fill_info(struct kvmppc_gs_buff *gsb, > > break; > > } > > case KVMPPC_GSID_LOGICAL_PVR: > > - rc = kvmppc_gse_put_u32(gsb, iden, > > - vcpu->arch.vcore->arch_compat); > > + /* > > + * Though 'arch_compat == 0' would mean the default > > + * compatibility, arch_compat, being a Guest Wide > > + * Element, cannot be filled with a value of 0 in GSB > > + * as this would result into a kernel trap. > > + * Hence, when `arch_compat == 0`, arch_compat should > > + * default to L1's PVR. > > + * > > + * Rework this when PowerVM supports a value of 0 > > + * for arch_compat for KVM API v2. > > + */ > > Is there an actual plan that PowerVM will support this in future? > > If so, how will a future kernel know that it's running on a version of > PowerVM that does support arch_compat == 0? > > Similarly how will we know when it's OK to drop support for this > workaround? I'm sending a v4 based on an off mailing list discussion. > > cheers ~Amit
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 52427fc2a33f..0b921704da45 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -391,6 +391,24 @@ static void kvmppc_set_pvr_hv(struct kvm_vcpu *vcpu, u32 pvr) /* Dummy value used in computing PCR value below */ #define PCR_ARCH_31 (PCR_ARCH_300 << 1) +static inline unsigned long map_pcr_to_cap(unsigned long pcr) +{ + unsigned long cap = 0; + + switch (pcr) { + case PCR_ARCH_300: + cap = H_GUEST_CAP_POWER9; + break; + case PCR_ARCH_31: + cap = H_GUEST_CAP_POWER10; + break; + default: + break; + } + + return cap; +} + static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat) { unsigned long host_pcr_bit = 0, guest_pcr_bit = 0, cap = 0; @@ -424,11 +442,9 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat) break; case PVR_ARCH_300: guest_pcr_bit = PCR_ARCH_300; - cap = H_GUEST_CAP_POWER9; break; case PVR_ARCH_31: guest_pcr_bit = PCR_ARCH_31; - cap = H_GUEST_CAP_POWER10; break; default: return -EINVAL; @@ -440,6 +456,12 @@ static int kvmppc_set_arch_compat(struct kvm_vcpu *vcpu, u32 arch_compat) return -EINVAL; if (kvmhv_on_pseries() && kvmhv_is_nestedv2()) { + /* + * 'arch_compat == 0' would mean the guest should default to + * L1's compatibility. In this case, the guest would pick + * host's PCR and evaluate the corresponding capabilities. + */ + cap = map_pcr_to_cap(guest_pcr_bit); if (!(cap & nested_capabilities)) return -EINVAL; } diff --git a/arch/powerpc/kvm/book3s_hv_nestedv2.c b/arch/powerpc/kvm/book3s_hv_nestedv2.c index 5378eb40b162..6042bdc70230 100644 --- a/arch/powerpc/kvm/book3s_hv_nestedv2.c +++ b/arch/powerpc/kvm/book3s_hv_nestedv2.c @@ -138,6 +138,7 @@ static int gs_msg_ops_vcpu_fill_info(struct kvmppc_gs_buff *gsb, vector128 v; int rc, i; u16 iden; + u32 arch_compat = 0; vcpu = gsm->data; @@ -347,8 +348,26 @@ static int gs_msg_ops_vcpu_fill_info(struct kvmppc_gs_buff *gsb, break; } case KVMPPC_GSID_LOGICAL_PVR: - rc = kvmppc_gse_put_u32(gsb, iden, - vcpu->arch.vcore->arch_compat); + /* + * Though 'arch_compat == 0' would mean the default + * compatibility, arch_compat, being a Guest Wide + * Element, cannot be filled with a value of 0 in GSB + * as this would result into a kernel trap. + * Hence, when `arch_compat == 0`, arch_compat should + * default to L1's PVR. + * + * Rework this when PowerVM supports a value of 0 + * for arch_compat for KVM API v2. + */ + if (!vcpu->arch.vcore->arch_compat) { + if (cpu_has_feature(CPU_FTR_ARCH_31)) + arch_compat = PVR_ARCH_31; + else if (cpu_has_feature(CPU_FTR_ARCH_300)) + arch_compat = PVR_ARCH_300; + } else { + arch_compat = vcpu->arch.vcore->arch_compat; + } + rc = kvmppc_gse_put_u32(gsb, iden, arch_compat); break; }