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

[Mirela Simonovic <mirela.simonovic@xxxxxxxxxx>]

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.
Of course, we need to test to confirm

>
> > It would fantastic to have that in this patch series, and might not be
> > too difficult to do. However, I also think that always waking up the
> > hardware domain could be a decent way to start and could be OK for this
> > patch series which is the very first to introduce suspend/resume
> > functionalities on Xen on ARM. But the limitation should be well
> > explained in the commit message, as Julien wrote, and possibly even as
> > an in-code comment with a TODO.
>

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