From: George Dunlap <george.dunlap@citrix.com>
To: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
Stefano Stabellini <sstabellini@kernel.org>
Cc: Artem_Mygaiev@epam.com,
Dario Faggioli <dario.faggioli@citrix.com>,
xen-devel@lists.xensource.com,
Andrii Anisov <andrii_anisov@epam.com>,
Julien Grall <julien.grall@arm.com>
Subject: Re: Notes on stubdoms and latency on ARM
Date: Tue, 23 May 2017 10:08:33 +0100 [thread overview]
Message-ID: <0ca190f0-772e-936e-4b14-c84dd03580df@citrix.com> (raw)
In-Reply-To: <CAOcqxo0djhKRRS_0F+zm9uGFNHb+Dtuj_h=yqBrSdD0+RRA05A@mail.gmail.com>
On 19/05/17 20:45, Volodymyr Babchuk wrote:
> Hi Stefano,
>
> On 18 May 2017 at 22:00, Stefano Stabellini <sstabellini@kernel.org> wrote:
>
>> Description of the problem: need for a place to run emulators and
>> mediators outside of Xen, with low latency.
>>
>> Explanation of what EL0 apps are. What should be their interface with
>> Xen? Could the interface be the regular hypercall interface? In that
>> case, what's the benefit compared to stubdoms?
> I imagined this as separate syscall interface (with finer policy
> rules). But this can be discussed, of course.
I think that's a natural place to start. But then you start thinking
about the details: this thing needs to be able to manage its own address
space, send and receive event channels / interrupts, &c &c -- and it
actually ends up looking exactly like a subset of what a stubdomain can
already do.
In which case -- why invent a new interface, instead of just reusing the
existing one?
>> The problem with stubdoms is latency and scheduling. It is not
>> deterministic. We could easily improve the null scheduler to introduce
>> some sort of non-preemptive scheduling of stubdoms on the same pcpus of
>> the guest vcpus. It would still require manually pinning vcpus to pcpus.
> I see couple of other problems with stubdoms. For example, we need
> mechanism to load mediator stubdom before dom0.
There are a couple of options here. You could do something like the
Xoar project [1] did, and have Xen boot a special-purpose "system
builder" domain, which would start both the mediator and then a dom0.
Or you could have a mechanism for passing more than one domain / initrd
to Xen, and pass Xen both the mediator stubdom as well as the kernel for
dom0.
[1] tjd.phlegethon.org/words/sosp11-xoar.pdf
>> Then, we could add a sched_op hypercall to let the schedulers know that
>> a stubdom is tied to a specific guest domain.
> What if one stubdom serves multiple domains? This is TEE use case.
Then you don't make that hypercall. :-) In any case you certainly can't
use an EL0 app for that, at least the way we've been describing it.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-05-23 9:08 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 19:00 Notes on stubdoms and latency on ARM Stefano Stabellini
2017-05-19 19:45 ` Volodymyr Babchuk
2017-05-22 21:41 ` Stefano Stabellini
2017-05-26 19:28 ` Volodymyr Babchuk
2017-05-30 17:29 ` Stefano Stabellini
2017-05-30 17:33 ` Julien Grall
2017-06-01 10:28 ` Julien Grall
2017-06-17 0:17 ` Volodymyr Babchuk
2017-05-31 9:09 ` George Dunlap
2017-05-31 15:53 ` Dario Faggioli
2017-05-31 16:17 ` Volodymyr Babchuk
2017-05-31 17:45 ` Stefano Stabellini
2017-06-01 10:48 ` Julien Grall
2017-06-01 10:52 ` George Dunlap
2017-06-01 10:54 ` George Dunlap
2017-06-01 12:40 ` Dario Faggioli
2017-06-01 15:02 ` George Dunlap
2017-06-01 18:27 ` Stefano Stabellini
2017-05-31 17:02 ` George Dunlap
2017-06-17 0:14 ` Volodymyr Babchuk
2017-06-19 9:37 ` George Dunlap
2017-06-19 17:54 ` Stefano Stabellini
2017-06-19 18:36 ` Volodymyr Babchuk
2017-06-20 10:11 ` Dario Faggioli
2017-07-07 15:02 ` Volodymyr Babchuk
2017-07-07 16:41 ` Dario Faggioli
2017-07-07 17:03 ` Volodymyr Babchuk
2017-07-07 21:12 ` Stefano Stabellini
2017-07-12 6:14 ` Dario Faggioli
2017-07-17 9:25 ` George Dunlap
2017-07-17 10:04 ` Julien Grall
2017-07-17 11:28 ` George Dunlap
2017-07-19 11:21 ` Julien Grall
2017-07-20 9:25 ` Dario Faggioli
2017-07-20 9:10 ` Dario Faggioli
2017-07-20 8:49 ` Dario Faggioli
2017-07-08 14:26 ` Dario Faggioli
2017-06-20 10:45 ` Julien Grall
2017-06-20 16:23 ` Volodymyr Babchuk
2017-06-21 10:38 ` Julien Grall
2017-06-19 18:26 ` Volodymyr Babchuk
2017-06-20 10:00 ` Dario Faggioli
2017-06-20 10:30 ` George Dunlap
2017-05-23 7:11 ` Dario Faggioli
2017-05-26 20:09 ` Volodymyr Babchuk
2017-05-27 2:10 ` Dario Faggioli
2017-05-23 9:08 ` George Dunlap [this message]
2017-05-26 19:43 ` Volodymyr Babchuk
2017-05-26 19:46 ` Volodymyr Babchuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ca190f0-772e-936e-4b14-c84dd03580df@citrix.com \
--to=george.dunlap@citrix.com \
--cc=Artem_Mygaiev@epam.com \
--cc=andrii_anisov@epam.com \
--cc=dario.faggioli@citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).