[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





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

 


Rackspace

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