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

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

Renaming the subject + adding more people in the conversation as this is not related to only ARM anymore.

On 11/05/17 16:19, Volodymyr Babchuk wrote:
Hi Stefano,

On 10 May 2017 at 21:24, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
I just want to point out that the comparision with tasklets is not
helpful. Tasklets involve the idle vcpu, which we are trying to step away
from because it increases irq latency. Tasklets don't provide any
isolation. The context switch model for the idle vcpu and for EL0 apps
is different, thus it has a different cost.

I think we shouldn't mention tasklets in this thread any longer.
Yep, you are right. Let's forget about tasklets and focus on EL0 apps.

I want summarize political (opposed to technical) part of the discussion.

We, here at EPAM, viewed EL0 apps primarily as a way to extend
hypervisor. Because when it comes to embedded and automotive, there
arise some ugly things, that are needed at hypervisor level:
TEE mediators (OP-TEE is a good TEE, but for example there is TI's
MSHIELD with deeply proprietary license), device drivers for vcopros,
device drivers for cpufreq, and so on.
Some of this things can't be included in hypervisor due to legal
issues, some - because of code size or complexity. And we can't run
them in stubdoms, because stubdoms are slow for certain use-cases, in
some cases they are insecure, in some cases they just don't fit at

On other hand you consider EL0 apps as ideal host for emulators only.
I can see your point, because XEN was always viewed as hypervisor for
But servers have different requirements in comparison to embedded
applications. Traditional servers does not use hardware accelerated
video decoders, they don't need to disable cpu's or scale frequencies
to preserve energy (okay, they need to, but it is not as pressing, as
on battery-powered device), there almost no proprietary code (or even
proprietary blobs, argh!).
Looks like virtualization on embedded is the next big thing. Linux
kernel was able to satisfy both parties. I hope that XEN can do the

So, going back to EL0 apps. Honestly, I'd prefer not to use them as
extension mechanism. Yes, they provide isolation, but interfacing with
them will be painful. Probably we can leave them to emulators only
(but as I can see, PL011 emulator is going to be merged right into
hypervisor. Will be there need for other emulators?).
What I really want to ask: what do you thing about old good modules
like ones in linux kernel? There will be no isolation, this is bad.
 - you can load proprietary modules if you want to
 - they are fast
 - you can interface with them in a nativest way possible: just call a function

Artem, could you please comment from your side?

Julien Grall

Xen-devel mailing list



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