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

From: Julien Grall <julien.grall@arm.com>
To: Mirela Simonovic <mirela.simonovic@aggios.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: nd@arm.com, Saeed Nowshadi <saeed.nowshadi@xilinx.com>,
	Davorin Mista <dm@aggios.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Dario Faggioli <dfaggioli@suse.com>,
	Stefano Stabellini <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH 17/18] xen/arm: Resume Dom0 after Xen resumes
Date: Tue, 27 Nov 2018 18:36:46 +0000	[thread overview]
Message-ID: <826f5a0f-67cd-c544-a8a8-38d861bf80a7@arm.com> (raw)
In-Reply-To: <CAKPH-Ngxu7a-pxoM6+ffBYiiFa3zeUt=ns6gaYpyJpFth4xE3A@mail.gmail.com>

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@kernel.org> 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@kernel.org> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel