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

[Julien Grall <julien.grall@xxxxxxx>]

On 11/17/18 4:01 PM, Mirela Simonovic wrote:
> Hi,
Hi Mirela,

> 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.
Such change cannot be easily dropped because some hardware domain OS may 
rely on that behavior.
I am also interested to see how this is going to fit with the Dom0less 
use case. The end goal is to have no Dom0/Hardware domain. So how do you 
expect suspend/resume to work in that case? Note that I am not asking to 
implement it :).
Cheers,

--
Julien Grall

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