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

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

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
> QEMU.
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
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel