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
