qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v3] spapr: add splpar hcalls H_PROD, H_CONFER


From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH v3] spapr: add splpar hcalls H_PROD, H_CONFER
Date: Wed, 17 Apr 2019 11:59:34 +1000
User-agent: Mutt/1.11.3 (2019-02-01)

On Tue, Apr 16, 2019 at 02:55:52PM +1000, Nicholas Piggin wrote:
> These implementations have a few deficiencies that are noted, but are
> good enough for Linux to use.
> 
> Signed-off-by: Nicholas Piggin <address@hidden>
> ---
> 
> v3: Removed wrong comment about GPR3, drop H_JOIN for now (at least until
> it is tested some more in Linux/KVM), and expand the comment about not
> prod bit.
> 
>  hw/ppc/spapr_hcall.c | 71 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 8a736797b9..8892ad008b 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1065,6 +1065,74 @@ static target_ulong h_cede(PowerPCCPU *cpu, 
> SpaprMachineState *spapr,
>      return H_SUCCESS;
>  }
>  
> +static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
> +                           target_ulong opcode, target_ulong *args)
> +{
> +    target_long target = args[0];
> +    CPUState *cs = CPU(cpu);
> +
> +    /*
> +     * This does not do a targeted yield or confer, but check the parameter
> +     * anyway. -1 means confer to all/any other CPUs.
> +     */
> +    if (target != -1 && !CPU(spapr_find_cpu(target))) {
> +        return H_PARAMETER;
> +    }
> +
> +    /*
> +     * PAPR calls for waiting until proded in this case (or presumably
> +     * an external interrupt if MSR[EE]=1, without dispatch sequence count
> +     * check.

Is this comment complete?  It's missing a closing parenthesis at the
very least.

> +     */
> +    if (cpu == spapr_find_cpu(target)) {
> +        cs->halted = 1;
> +        cs->exception_index = EXCP_HALTED;
> +        cs->exit_request = 1;
> +
> +        return H_SUCCESS;
> +    }
> +
> +    /*
> +     * This does not implement the dispatch sequence check that PAPR calls 
> for,
> +     * but PAPR also specifies a stronger implementation where the target 
> must
> +     * be run (or EE, or H_PROD) before H_CONFER returns. Without such a hard
> +     * scheduling requirement implemented, there is no correctness reason to
> +     * implement the dispatch sequence check.
> +     */
> +    cs->exception_index = EXCP_YIELD;
> +    cpu_loop_exit(cs);
> +
> +    return H_SUCCESS;
> +}
> +
> +static target_ulong h_prod(PowerPCCPU *cpu, SpaprMachineState *spapr,
> +                           target_ulong opcode, target_ulong *args)
> +{
> +    target_long target = args[0];
> +    CPUState *cs;
> +
> +    /*
> +     * PAPR specifies there should be a prod flag should be associated with
> +     * a vCPU, which gets set here, tested by H_CEDE, and cleared any time
> +     * the vCPU is dispatched, including via preemption.
> +     *
> +     * We don't implement this because it is not used by Linux. The bit would
> +     * be difficult or impossible to use properly because preemption can not
> +     * be prevented so dispatch sequence count would have to somehow be used
> +     * to detect it.

Hm.  AFAIK the dispatch sequence count only exists with KVM, so I
don't see how testing it would fit with a userspace implementation of PROD.

> +     */
> +
> +    cs = CPU(spapr_find_cpu(target));
> +    if (!cs) {
> +        return H_PARAMETER;
> +    }
> +
> +    cs->halted = 0;
> +    qemu_cpu_kick(cs);
> +
> +    return H_SUCCESS;
> +}
> +
>  static target_ulong h_rtas(PowerPCCPU *cpu, SpaprMachineState *spapr,
>                             target_ulong opcode, target_ulong *args)
>  {
> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
>      /* hcall-splpar */
>      spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
>      spapr_register_hypercall(H_CEDE, h_cede);
> +    spapr_register_hypercall(H_CONFER, h_confer);
> +    spapr_register_hypercall(H_PROD, h_prod);
> +
>      spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset);

You're no longer enabling the KVM CONFER and PROD hypercalls.  Are
they enabled by default, or is that an intentional change?

>      /* processor register resource access h-calls */

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]