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

[Julien Grall <julien.grall@xxxxxxx>]

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
> all.
>
> 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
> servers.
> 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
> same.
>
> 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.
> But:
>  - 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
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel