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 5:02 PM Mirela Simonovic
<mirela.simonovic@xxxxxxxxxx> wrote:
>
> On Sat, Nov 17, 2018 at 5:01 PM Mirela Simonovic
> <mirela.simonovic@xxxxxxxxxx> wrote:
> >
> > 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

Forgot to answer this - when someone needs a toolstack, it will try to
type. That will raise a UART interrupt (UART used by Xen console). It
could be implemented that a UART interrupt by default wakes up dom0 if
it's asleep.
But I would keep anything like that out of this series.

> > >
> > > 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,
> resumes
>
> > 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