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

[George Dunlap <george.dunlap@citrix.com>]

On 11/05/17 16:35, Julien Grall wrote:
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini <sstabellini@kernel.org>
>> 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

Even better would be to skip the module-loading step entirely, and just
compile proprietary code directly into your Xen binary.

Both solutions, unfortunately, are illegal.*

 -George

* I am not a lawyer, and this is not legal advice; but see this
presentation for a bit more information:
http://www.kroah.com/log/linux/ols_2006_keynote.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel