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

[Andrii Anisov <andrii_anisov@epam.com>]

On 21.04.17 23:58, Stefano Stabellini wrote:
> Hello Andrii,
>
> could you please use plain text (not HTML) in your emails?
My bad. Will be checking delivery format settings carefully.

> On Fri, 21 Apr 2017, Andrii Anisov wrote:
>> 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.
 From my last conversation with Volodymyr I've got a feeling that 
notions "EL0" and "XEN native application" must be pretty orthogonal.
In [1] Volodymyr got no performance gain from changing domain's 
exception level from EL1 to EL0.
Only when Volodymyr stripped the domain's context  abstraction (i.e. 
dropped GIC context store/restore) some noticeable results were reached.
So I treat his results as a "light domain" experiment.
For me it is interesting how configurable and light the "domain" 
abstraction could be and when it starts to be treated as a "native 
application"?

> In that case, stubdoms or regular driver domains are a
> better choice.
Sorry for my ignorance, but is there any difference between regular 
domains and stub domains from hypervisor point of view?

[1]http://marc.info/?l=xen-devel&m=149088856116797&w=2  - benchmark results

-- 

*Andrii Anisov*



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