Re: [Xen-devel] [PATCH 17/18] xen/arm: Resume Dom0 after Xen resumes

[Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>]

Hi,

On Sat, Nov 17, 2018 at 12:06 AM Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
>
> On Sat, 17 Nov 2018, Dario Faggioli wrote:
> > On Fri, 2018-11-16 at 21:58 +0000, Julien Grall wrote:
> > > On 16/11/2018 21:41, Mirela Simonovic wrote:
> > > > On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
> > > > <sstabellini@xxxxxxxxxx> wrote:
> > > > > > It should be possible to figure out which domain needs to
> > > > > > awaken from
> > > > > > there.
> > > > >
> > > > > Actually, evtchn_send eventually will trigger a proper interrupt
> > > > > injection into the domain
> > > > > (xen/arch/arm/vgic.c:arch_evtchn_inject),
> > > > > which will necessarely wake it up. So it is possible that it will
> > > > > already work without any need for additional changes?
> > > > >
> > > >
> > > > Absolutely, that sounds great :) Then we could just drop this
> > > > patch.
> > >
> > > I don't think you can drop this patch... As you tie the host suspend
> > > to
> > > the hardware domain suspend, it may makes sense to resume at the same
> > > time.
> > >
> > FWIW, I think that too.
> >
> > In fact, let's assume a *fully* disaggregated setup, where dom0 only
> > has the toolstack, while it has no hardware, no PV backend, etc... If
> > we don't resume it explicitly together with Xen, who is going to resume
> > it? :-O
>
> Yes, that's right. However, it should work for driver domains: there is
> no need to wake up driver domains explicitly because they will be
> woken up by the frontends?
>

I think we all agree, except some of us weren't so clear about it :)
For now, dom0 issues suspend and should resume as well when Xen
suspends. This is done in the series, resume is covered by this patch,
and commit message should be clarified.

If a domU has a backend, we should verify that it can be woken-up by
an event triggered by a frontend driver in another domain.

One day, this patch could be dropped/reverted if one come up with a
different logic for triggering Xen suspend. This should be of the
table for now, but a good option to remember for future.

>
> > <<This happens because I choose it to happen!>> (Raistlin Majere)
> > -----------------------------------------------------------------
> > Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> > Software Engineer @ SUSE https://www.suse.com/
> >

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