Re: [PATCH RESEND 05/15] ppc: spapr: Introduce cap-nested-papr for nested PAPR API

[Harsh Prateek Bora]

On 9/7/23 07:19, Nicholas Piggin wrote:
> On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> > This patch introduces a new cmd line option cap-nested-papr to enable
> > support for nested PAPR API by setting the nested.api version accordingly.
> > It requires the user to launch the L0 Qemu in TCG mode and then L1 Linux
> > can then launch the nested guest in KVM mode. Unlike cap-nested-hv,
> > this is meant for nested guest on pseries (PowerVM) where L0 retains
> > whole state of the nested guest. Both APIs are thus mutually exclusive.
> > Support for related hcalls is being added in next set of patches.
>
> This changelog could use some work too.
>
> "Introduce a SPAPR capability cap-nested-papr with provides a nested
(s/with/which?)
> HV facility to the guest. This is similar to cap-nested-hv, but uses
> a different (incompatible) API and so they are mutually exclusive."
We may want to emphasize that nested virtualization on Power uses only 
this new API, whereas the other API was targeted towards PowerNV but 
never became part of the PAPR spec?

> You could add some documentation to say recent Linux pseries guests
> support both, and explain more about KVM and PowerVM support there too,
> if it is relevant.

Sure, will update.

> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
> > ---
> >   hw/ppc/spapr.c         |  2 ++
> >   hw/ppc/spapr_caps.c    | 48 ++++++++++++++++++++++++++++++++++++++++++
> >   include/hw/ppc/spapr.h |  5 ++++-
> >   3 files changed, 54 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 0aa9f21516..cbab7a825f 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -2092,6 +2092,7 @@ static const VMStateDescription vmstate_spapr = {
> >           &vmstate_spapr_cap_fwnmi,
> >           &vmstate_spapr_fwnmi,
> >           &vmstate_spapr_cap_rpt_invalidate,
> > +        &vmstate_spapr_cap_nested_papr,
> >           NULL
> >       }
> >   };
> > @@ -4685,6 +4686,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> > void *data)
> >       smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_WORKAROUND;
> >       smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
> >       smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
> > +    smc->default_caps.caps[SPAPR_CAP_NESTED_PAPR] = SPAPR_CAP_OFF;
> >       smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
> >       smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_ON;
> >       smc->default_caps.caps[SPAPR_CAP_FWNMI] = SPAPR_CAP_ON;
> > diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> > index a3a790b026..d3b9f107aa 100644
> > --- a/hw/ppc/spapr_caps.c
> > +++ b/hw/ppc/spapr_caps.c
> > @@ -491,6 +491,44 @@ static void cap_nested_kvm_hv_apply(SpaprMachineState 
> > *spapr,
> >       }
> >   }
> >   
> > +static void cap_nested_papr_apply(SpaprMachineState *spapr,
> > +                                    uint8_t val, Error **errp)
> > +{
> > +    ERRP_GUARD();
> > +    PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
> > +    CPUPPCState *env = &cpu->env;
> > +
> > +    if (!val) {
> > +        /* capability disabled by default */
> > +        return;
> > +    }
> > +
> > +    if (tcg_enabled()) {
> > +        if (!(env->insns_flags2 & PPC2_ISA300)) {
> > +            error_setg(errp, "Nested-PAPR only supported on POWER9 and later");
> > +            error_append_hint(errp,
> > +                              "Try appending -machine cap-nested-papr=off\n");
> > +            return;
> > +        }
> > +        spapr->nested.api = NESTED_API_PAPR;
>
> I'm not seeing any mutual exclusion with the other cap here. What if
> you enable them both? Lucky dip?
>
> It would actually be nice to enable both even if you just choose the
> mode after the first hcall is made. I think you could actually support
> both (even concurrently) quite easily.
>
> For now this is probably okay if you fix mutex.

Thanks for catching this. Will fix.

> > +    } else if (kvm_enabled()) {
> > +        /*
> > +         * this gets executed in L1 qemu when L2 is launched,
> > +         * needs kvm-hv support in L1 kernel.
> > +         */
> > +        if (!kvmppc_has_cap_nested_kvm_hv()) {
> > +            error_setg(errp,
> > +                       "KVM implementation does not support Nested-HV");
> > +            error_append_hint(errp,
> > +                              "Try appending -machine cap-nested-hv=off\n");
> > +        } else if (kvmppc_set_cap_nested_kvm_hv(val) < 0) {
> > +            error_setg(errp, "Error enabling cap-nested-hv with KVM");
> > +            error_append_hint(errp,
> > +                              "Try appending -machine cap-nested-hv=off\n");
> > +        }
>
> This is just copy and pasted from the other cap, isn't it?
Yeh, error logs needs to be rephrased.

> > +    }
> > +}
> > +
> >   static void cap_large_decr_apply(SpaprMachineState *spapr,
> >                                    uint8_t val, Error **errp)
> >   {
> > @@ -736,6 +774,15 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> >           .type = "bool",
> >           .apply = cap_nested_kvm_hv_apply,
> >       },
> > +    [SPAPR_CAP_NESTED_PAPR] = {
> > +        .name = "nested-papr",
> > +        .description = "Allow Nested PAPR (Phyp)",
> > +        .index = SPAPR_CAP_NESTED_PAPR,
> > +        .get = spapr_cap_get_bool,
> > +        .set = spapr_cap_set_bool,
> > +        .type = "bool",
> > +        .apply = cap_nested_papr_apply,
> > +    },
>
> Should scrub "Phyp". "Phyp" and PowerVM also doesn't mean anything for
> us really. We both implement PAPR. "Nested PAPR" is jibberish for a user
> as well -- "Allow Nested KVM-HV (PAPR API)" or similar might be a bit
> better.
I think "Allow Nested-HV (PAPR API)" may be better since L0 is the 
hypervisor here which takes care of nested guests. We may want to avoid 
the term "Nested KVM" which usually means KVM on KVM as hypervisor.
Also, AFAIK, the former API never became part of PAPR spec, not sure if 
it is appropriate to say - both implement PAPR ?

regards,
Harsh

> Thanks,
> Nick
>
> >       [SPAPR_CAP_LARGE_DECREMENTER] = {
> >           .name = "large-decr",
> >           .description = "Allow Large Decrementer",
> > @@ -920,6 +967,7 @@ SPAPR_CAP_MIG_STATE(sbbc, SPAPR_CAP_SBBC);
> >   SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
> >   SPAPR_CAP_MIG_STATE(hpt_maxpagesize, SPAPR_CAP_HPT_MAXPAGESIZE);
> >   SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
> > +SPAPR_CAP_MIG_STATE(nested_papr, SPAPR_CAP_NESTED_PAPR);
> >   SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
> >   SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
> >   SPAPR_CAP_MIG_STATE(fwnmi, SPAPR_CAP_FWNMI);
> > diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> > index c8b42af430..8a6e9ce929 100644
> > --- a/include/hw/ppc/spapr.h
> > +++ b/include/hw/ppc/spapr.h
> > @@ -81,8 +81,10 @@ typedef enum {
> >   #define SPAPR_CAP_RPT_INVALIDATE        0x0B
> >   /* Support for AIL modes */
> >   #define SPAPR_CAP_AIL_MODE_3            0x0C
> > +/* Nested PAPR */
> > +#define SPAPR_CAP_NESTED_PAPR           0x0D
> >   /* Num Caps */
> > -#define SPAPR_CAP_NUM                   (SPAPR_CAP_AIL_MODE_3 + 1)
> > +#define SPAPR_CAP_NUM                   (SPAPR_CAP_NESTED_PAPR + 1)
> >   
> >   /*
> >    * Capability Values
> > @@ -1005,6 +1007,7 @@ extern const VMStateDescription vmstate_spapr_cap_sbbc;
> >   extern const VMStateDescription vmstate_spapr_cap_ibs;
> >   extern const VMStateDescription vmstate_spapr_cap_hpt_maxpagesize;
> >   extern const VMStateDescription vmstate_spapr_cap_nested_kvm_hv;
> > +extern const VMStateDescription vmstate_spapr_cap_nested_papr;
> >   extern const VMStateDescription vmstate_spapr_cap_large_decr;
> >   extern const VMStateDescription vmstate_spapr_cap_ccf_assist;
> >   extern const VMStateDescription vmstate_spapr_cap_fwnmi;