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

[Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>]

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?
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?

Thanks,
Mirela

> Cheers,
>
> --
> Julien Grall

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