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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@xxxxxxxxxx> 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.

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