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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Mirela,

On 11/29/18 2:02 PM, Mirela Simonovic wrote:
> Hi Julien,
>
> On Tue, Nov 27, 2018 at 7:36 PM Julien Grall <julien.grall@xxxxxxx> wrote:
> > 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 :).
>  From the implementation perspective and future changes which would be
> required in this series it's not going to be the problem to support
> dom0less approach - just one line of code (the if statement that
> checks whether the hardware domain suspended) has to be replaced with
> some other check. That other check would be a new condition to suspend
> Xen that needs to be implemented. What that check would do depends on
> the system architecture and target use cases that are specific to
> dom0less architecture. I'm not so familiar with dom0less work, so
> can't really say what would be the best approach to suspend condition
> rules.
> Do you have some whitepaper or anything similar that describes an
> example of a target system architecture and/or use cases for dom0less
> setup?
Have a look at docs/features/dom0less.markdown

> In dom0less world, who creates other domains? Is some domain still
> more privileged than the others? E.g. is there a domain which knows
> about other domains in the system so that it could do the coordination
> in EL1?
It depends on your setup. In some setup, all the domains could be 
created by Xen and therefore there are no guest more privileged than 
one. But in other setup, you may still have a privilege domain (i.e 
hwdom/dom0).
What I want to avoid is if we tie ourself to an ABI than can't be 
changed anymore. In the guest context, I guess considering that Xen will 
suspend/resuming when Xen is suspending/resuming is probably a safe bet.
Cheers,

--
Julien Grall

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