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

[Julien Grall <Julien.Grall@xxxxxxx>]

On 16/11/2018 21:41, Mirela Simonovic wrote:
> Hi Stefano,
> 
> On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
> <sstabellini@xxxxxxxxxx> wrote:
>>
>> On Fri, 16 Nov 2018, Stefano Stabellini wrote:
>>> On Fri, 16 Nov 2018, Julien Grall wrote:
>>>> On 16/11/2018 12:34, Mirela Simonovic wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi Mirela,
>>>>
>>>>>
>>>>> On Fri, Nov 16, 2018 at 12:44 PM Julien Grall <julien.grall@xxxxxxx> 
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16/11/2018 11:29, Mirela Simonovic wrote:
>>>>>>> On Fri, Nov 16, 2018 at 11:33 AM Mirela Simonovic
>>>>>>> <mirela.simonovic@xxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> Hi Julien,
>>>>>>>>
>>>>>>>> On Thu, Nov 15, 2018 at 9:31 PM Julien Grall <julien.grall@xxxxxxx>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
>>>>>>>>>> The resume of Dom0 should always follow Xen's resume. This is
>>>>>>>>>> done by unblocking the first vCPU of Dom0.
>>>>>>>>>
>>>>>>>>> Please explain why you always need to resume Dom0 afterwards.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We don't need to, but that is what is promised in the design spec.
>>>>>>
>>>>>> You surely had some rationale when writing the promise in the design
>>>>>> document,
>>>>>> right?
>>>>>>
>>>>>> So what is the reason behind it? I don't want to resume a domain if 
>>>>>> that's
>>>>>> not
>>>>>> necessary.
>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> To be more specific - a domU that doesn't depend on dom0 can resume
>>>>>>> and work happily without dom0 being resumed, i.e. just Xen and domU
>>>>>>> resume. So patch "[PATCH 17/18] xen/arm: Resume Dom0 after Xen
>>>>>>> resumes" is not a must (when there are no PV drivers involved).
>>>>>>
>>>>>> PV backends don't necessarily reside in the hardware domain. So how is
>>>>>> this
>>>>>> going to work for the other case?
>>>>>>
>>>>>
>>>>> I honestly believe that this is not necessary, and is sub-optimal. It
>>>>> relies on an assumption that dom0 contains all the PV drivers, which
>>>>> is not always correct.
>>>>
>>>> Well, there are other reasons to resume the hardware domain. The hardware
>>>> domain owns most the devices and may be part of the suspend/resume path.
>>>>
>>>> As you tie the host suspend to the hardware domain suspend, it may makes 
>>>> sense
>>>> to resume at the same time. It is the kind of rationale I would expect in 
>>>> the
>>>> commit message.
>>>>
>>>>> I would prefer if someone can tell us that any frontend will trigger
>>>>> an event to the backend, and the event would go through Xen. That way,
>>>>> this event would cause a domain containing the backend driver to
>>>>> resume. I think this is the best possible solution, but it relies on
>>>>> an assumption that the event will go through Xen, and I'm not
>>>>> knowledgeable enough to claim that this is indeed the case.
>>>>
>>>> I think it is should work, the best way to find out if building a test case
>>>> for it.
>>>
>>> Yes, PV protocols use hypercalls to send notifications to the other end.
>>> Specifically, the function at the Linux side is
>>> include/xen/events.h:notify_remote_via_evtchn. The Xen implementation
>>> for the hypercall is xen/common/event_channel.c:evtchn_send, where 'rd'
>>> is the destination domain.
>>>
>>> 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.

Otherwise we should provide a separate hypercall to suspend/resume the host.

The whole point of the thread is we need to document why the decision 
was made in one way or another. So when someone look at it in 2 years 
time, we know why it has been done like that.

Cheers,

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