xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).