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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Andrii,

On 24/04/2017 17:56, Andrii Anisov wrote:
> On 21.04.17 23:58, Stefano Stabellini wrote:
> > 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.
Do you have numbers for part that take times in the save/restore? You 
mention GIC and I am a bit surprised you don't mention FPU.
I would have a look at optimizing the context switch path. Some ideas:
	- there are a lot of unnecessary isb/dsb. The registers used by the 
guests only will be synchronized by eret.
        - FPU is taking time to save/restore, you could make it lazy
	- It might be possible to limit the number of LRs saved/restored 
depending on the number of LRs used by a domain.
        - ...

If the numbers are still bad, then we can start stripping some part (for 
instance you may not need FPU).
Cheers,

--
Julien Grall

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