Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend

[Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>]

Hi Julien,

On Thu, Nov 15, 2018 at 7:23 PM Julien Grall <julien.grall@xxxxxxx> wrote:
>
> Hi Mirela,
>
> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > When Dom0 finalizes its suspend procedure the suspend of Xen is
> > triggered by calling system_suspend(). Dom0 finalizes the suspend from
> > its boot core (VCPU#0), which could be mapped to any physical CPU,
> > i.e. the system_suspend() function could be executed by any physical
> > CPU. Since Xen suspend procedure has to be run by the boot CPU
> > (non-boot CPUs will be disabled at some point in suspend procedure),
> > system_suspend() execution has to continue on CPU#0.
> >
> > When the system_suspend() returns 0, it means that the system was
> > suspended and it is coming out of the resume procedure. Regardless
> > of the system_suspend() return value, after this function returns
> > Xen is fully functional, and its state, including all devices and data
> > structures, matches the state prior to calling system_suspend().
> > The status is returned by system_suspend() for debugging/logging
> > purposes and function prototype compatibility.
> >
> > Signed-off-by: Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>
> > Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xxxxxxxxxx>
> > ---
> >   xen/arch/arm/suspend.c | 34 ++++++++++++++++++++++++++++++++++
> >   1 file changed, 34 insertions(+)
> >
> > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
> > index f2338e41db..21b45f8248 100644
> > --- a/xen/arch/arm/suspend.c
> > +++ b/xen/arch/arm/suspend.c
> > @@ -112,11 +112,20 @@ static void vcpu_suspend(register_t epoint, 
> > register_t cid)
> >       _arch_set_info_guest(v, &ctxt);
> >   }
> >
> > +/* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
> > +static long system_suspend(void *data)
> > +{
> > +    BUG_ON(system_state != SYS_STATE_active);
> > +
> > +    return -ENOSYS;
> > +}
> > +
> >   int32_t domain_suspend(register_t epoint, register_t cid)
> >   {
> >       struct vcpu *v;
> >       struct domain *d = current->domain;
> >       bool is_thumb = epoint & 1;
> > +    int status;
> >
> >       dprintk(XENLOG_DEBUG,
> >               "Dom%d suspend: epoint=0x%"PRIregister", 
> > cid=0x%"PRIregister"\n",
> > @@ -156,6 +165,31 @@ int32_t domain_suspend(register_t epoint, register_t 
> > cid)
> >        */
> >       vcpu_block_unless_event_pending(current);
> >
> > +    /* If this was dom0 the whole system should suspend: trigger Xen 
> > suspend */
> > +    if ( is_hardware_domain(d) )
> > +    {
> > +        /*
> > +         * system_suspend should be called when Dom0 finalizes the suspend
> > +         * procedure from its boot core (VCPU#0). However, Dom0's VCPU#0 
> > could
> > +         * be mapped to any PCPU (this function could be executed by any 
> > PCPU).
> > +         * The suspend procedure has to be finalized by the PCPU#0 
> > (non-boot
> > +         * PCPUs will be disabled during the suspend).
> > +         */
> > +        status = continue_hypercall_on_cpu(0, system_suspend, NULL);
> > +        /*
> > +         * If an error happened, there is nothing that needs to be done 
> > here
> > +         * because the system_suspend always returns in fully functional 
> > state
> > +         * no matter what the outcome of suspend procedure is. If the 
> > system
> > +         * suspended successfully the function will return 0 after the 
> > resume.
> > +         * Otherwise, if an error is returned it means Xen did not 
> > suspended,
> > +         * but it is still in the same state as if the system_suspend was 
> > never
> > +         * called. We dump a debug message in case of an error for 
> > debugging/
> > +         * logging purpose.
> > +         */
> > +        if ( status )
> > +            dprintk(XENLOG_ERR, "Failed to suspend, errno=%d\n", status);
> > +    }
>
> After discussing we Stefano today, I have one more question regarding
> Dom0 suspend.
>
>  From my understanding, the host may resume because of an event
> targeting a guest. This means that Dom0 would still be blocked. As Dom0
> would contain PV backend, how do you expect this to work?
>
> Is there any potential dependency between frontend and backend? Or would
> Dom0 be resume when the PV frontend probe the backend?
>

We have assumed that Dom0 has to resume whenever Xen resume. So if the
wake-up interrupt was targeted to DomU, the Dom0 would resume
regarless. Vice versa does not hold.
This is done in patch "[PATCH 17/18] xen/arm: Resume Dom0 after Xen
resumes" - the Dom0 is simply unblocked at the end of Xen's resume.

> Cheers,
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel