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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

George,

On 11 May 2017 at 20:14, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>> 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.
Okay, point taken.

>>> ...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?
Well... Device drives? Emulators? For example, if I will write bunch
of good and neat GPL drivers for some SoC and I'll promise to maintain
them, will you include them into upstream?
Or I will write emulator for some arcane device, will it be merged
into upstream?
Real case: I will write OP-TEE mediator for one client and Google
Trusty mediator for other client. Every will have, say, 2,000 lines of
code. Are there changes, that they both will be merged into
hypervisor?

>>> 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.
Yes, we probably can. But any such solution will require some changes
in hypervisor to accommodate it. So, what we are currently doing? We
are discussing such solutions.

> 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?
Okay, I don't know no platform where you need proprietary blob to
scale frequency. And I hope, I never will encounter one.
But I can imagine it: some firmware binary that needs to be uploaded
into PMIC. Can we store this firmware in the hypervisor? I don't know.
I'm not a lawyer.

> 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.
Okay, I didn't know that it is illegal to load non-gpl modules into
Linux kernel. Thank you for sharing this knowledge. But now I'm
curios, why there are EXPORT_SYMBOL_GPL() and plain EXPORT_SYMBOL()? I
though it was intended to separate GPL and non-GPL code.
BTW, "non-GPL code" does not mean "closed-source code". It can be
LGPL, MIT, BSD, or Copyleft license. I can imagine proprietary license
which is compatible with BSD, but is incompatible with GPLv2.

Anyways, I have taken your point. No proprietary code in modules. What
about other parts of discussion? Are you against loadable modules in
any fashion? What about native apps?

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

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