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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 11/05/17 16:35, Julien Grall wrote:
> 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),

If you're going to use a deeply proprietary TEE mediator, then you need
to find yourself a deeply proprietary hypervisor to go along with it --
either one you pay a license fee for or one you develop yourself.  It
would almost certainly be cheaper to improve the open-source one than to
do either of those.

Or you can try mixing the two and see what happens; but that doesn't
seem like a very sound legal strategy to me.

>> ...some [things can't be included in hypervisor] because of code
>> size or complexity.

Sorry, just to be clear: below you mentioned modules as a solution, and
given the context this would be included.  So can you expand on what you
mean that there are things that 1) can't be included in the hypervisor
because of code size or complexity, but for which 2) loadable modules
would be a suitable solution?

>> 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.

For many of these, there are probably technical solutions that we could
come up with that would allow proprietary content (such as video
decoders &c) that would have suitable performance without needing access
to the Xen address space.

Maybe I'm just not familiar with things, but it's hard for me to imagine
why you'd need proprietary blobs to disable cpus or scale frequency.
Are these really such complex activities that it's worth investing
thousands of hours of developer work into developing proprietary
solutions that you license?

Loading proprietary modules into Linux is as illegal as it would be in
Xen.  Many people obviously do it anyway, but you are really putting
yourself at a risk of meeting a guy like Patrick McHardy[1], a private
individual with copyright on the Linux kernel who by some estimates has
made almost EUR 2m in the last few years suing companies for GPL violations.

 -George

[1] https://lwn.net/Articles/721458/

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