|
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.
--
Andrii Anisov
Lead
Systems Engineer
Office: +380
44 390 5457 x 66766
Cell: +380 50
5738852 Email: andrii_anisov@xxxxxxxx
Kyiv, Ukraine (GMT+3) epam.com
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s)
or entity(ies) to which it is addressed and contains
information that is legally privileged and confidential. If
you are not the intended recipient, or the person responsible
for delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. All
unintended recipients are obliged to delete this message and
destroy any printed copies.
|
