Re: [ARM] Native application design and discussion (I hope)

From: Stefano Stabellini <sstabellini@kernel.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrii Anisov <andrii_anisov@epam.com>,
	Volodymyr Babchuk <vlad.babchuk@gmail.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	george.dunlap@citrix.com, Xen Devel <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Artem Mygaiev <joculator@gmail.com>
Subject: Re: [ARM] Native application design and discussion (I hope)
Date: Fri, 21 Apr 2017 14:17:01 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1704211415180.19860@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <alpine.DEB.2.10.1704211352310.19860@sstabellini-ThinkPad-X260>

On Fri, 21 Apr 2017, Stefano Stabellini wrote:
> Hello Andrii,
> 
> could you please use plain text (not HTML) in your emails?
> 
> On Fri, 21 Apr 2017, Andrii Anisov wrote:
> > 
> > Hello,
> > 
> > On 20.04.17 23:20, Volodymyr Babchuk wrote:
> > 
> > Hi Stefano,
> > 
> > On 12 April 2017 at 22:17, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > 
> > On Wed, 12 Apr 2017, Dario Faggioli wrote:
> > 
> > On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
> > 
> > On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> > 
> > This is the most difficult problem that we need to solve as part of
> > this
> > work. It is difficult to have the right answer at the beginning,
> > before
> > seeing any code. If the app_container/app_thread approach causes
> > too
> > much duplication of work, the alternative would be to fix/improve
> > stubdoms (minios) until they match what we need. Specifically,
> > these
> > would be the requirements:
> > 
> > IMO, this stubdom way, is really really really interesting! :-)
> > 
> > 1) Determinism: a stubdom servicing a given guest needs to be
> > scheduled
> >    immediately after the guest vcpu traps into Xen. It needs to
> >    deterministic.
> > 
> > We will also need another type of application: one which is periodically called by XEN itself, not actually servicing any domain request. This is needed for a
> > coprocessor sharing framework scheduler implementation.
> 
> EL0 apps can be a powerful new tool for us to use, but they are not the
> solution to everything. This is where I would draw the line: if the
> workload needs to be scheduled periodically, then it is not a good fit
> for an EL0 app. In that case, stubdoms or regular driver domains are a
> better choice.
> 
> EL0 apps are a natural fit for emulators, when you have one instance per
> VM.
> 
> I am not completely convinced that they could be used for cases where
> you need one instance for all domains (even without periodic
> scheduling). I am not sure they could be made to work well that way.
> Stubdom or driver domains could be better fit for that use case too.

Although I'll add that some emulators running as EL0 apps might have to
register a timer with Xen because they might need to send periodical
interrupts to the guest (think of emulating a timer).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel