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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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?


> 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