On 21/04/17 15:42, Andrii Anisov wrote:
Hello,
Hi,
On 20.04.17 23:20, Volodymyr Babchuk wrote:
Hi Stefano,
On 12 April 2017 at 22:17, Stefano Stabellini <sstabell...@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.
I don't think we should think in term of type of application supported.
We should aim to have a generic interface we can maintain based on the
needs.
We can further restrict access to some interface for a given app. But I
would rather avoid to have different interfaces for each type of
application.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel