[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.