[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hello Stefano,

On 24.04.17 21:08, Stefano Stabellini wrote:
Stubdomains (stubdoms in short) are small domains, each running a single
application. Typically they run unikernels rather than a full fledged
operating system. A classic example is QEMU stubdoms on x86: one QEMU
stubdoms is started for each regular guest domain. Each QEMU stubdom
instance provides emulation for one guest - it runs one instance of
I'm wondering if there are any examples of practical usage of stub domains with ARM?

 From Xen point of view, they are regular domain, except that they are
privilege in regards to one particular guest only (they can map a page
of the guest they are servicing, but they cannot map any random page in
memory). If you do "xl list" you would see stubdoms in the output.
So they are the regular XEN domains with sort of specific permissions.
The advantages of using stubdoms are:
- they already exist
- their security properties are well known
Could you please point me to some up to date documentation about stubdoms and their security properties?
In this thread, we are discussing whether it makes sense to introduce a
*new* model, one that has different properties, therefore different
advantages and disadvantages. Let's call it EL0 apps.

An EL0 app is an application that runs on top of the Xen hypervisor
directly in EL0 mode. It is not a domain, and it doesn't show up on "xl
list". It runs on the same timeslot of the guest vcpu it is servicing.
It is scheduled deterministically: right after a guest vcpu traps into
the hypervisor. The build is simple. Writing an EL0 app should be
(almost) as simple as writing a regular emulator for Xen. An EL0
app is not scheduled, but it could register a timer with Xen. The
interface between EL0 apps and Xen is small: the number of
functionalities exposed are very limited.
Any reason to have an interface between XEN and EL0 app to be bound to an app functionality? Why not to introduce a generic (simplistic) interface and do not limit the functionality of the EL0 app?

The advantages of using EL0 apps are:
- scheduled deterministically
- faster context switch
- lower and deterministic latency
- EL0 apps execution time is accounted appropriately to the guest that
   they are servicing
Can't the EL0 app be servicing XEN itself?



*Andrii Anisov*

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.