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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Stefano,

>> 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.
> I can see that stubdoms can be slow if you require very low latencies.
> Scheduler optimizations (giving stubdoms an higher priority) might be
> able to improve on those.
Yeah, when I wrote "slow" I actually meant "have high latency". Thank
you for correction. Yep, they can be improved to a certain limit.

> But they are not insecure. Also, in what cases they don't fit at all?
About security... I had in mind that case, that we discussed on
community call: secure boot. Say, we put OP-TEE mediator into stubdom.
But as it is sensitive thing, we need to a) check it's signature, b)
create this stubdom before dom0 construction. From other points it as
secure as any other domain.

Regarding "don't fit at all": the virtual coprocessors use-case. I
don't see how we can put vGPU driver into a stubdomain.


>> On other hand you consider EL0 apps as ideal host for emulators only.
>
> Yes, EL0 apps are ideal for emulators, but not just emulators, anything
> that runs deterministically after a guest trap or a timer event could be
> a decent fit for an EL0 app. The issue is the interface between EL0 app
> and Xen, but that can be discussed and designed in a way to satisfy all
> parties.
Okay, we need to discuss it, but looks like this definition covers all
our use-cases.

> But we need to start from somewhere. I suggest you write a simple design
> document to explain the use-case for EL0 apps and their interfaces to
> the rest of the system. We can take the discussion from there. We might
> be able to reach a consensus on a design that works for everybody.
>
> We need a concrete proposal to start from though.
Yes, I agree. Now, when we have discussed this in ML, I have better
vision on this topic. I'll try to present some design document in the
next week.

>> 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.
> I think that this has not much to do with embedded vs server; it's more
> about the need of supporting new, more complex, hardware and firmware
> interfaces.
Yep, this is more precise.

>
>> 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
>
> Proprietary modules are a legal minefield. They are best avoided even in
> Linux. Fortunately, both EL0 apps and stubdoms could be proprietary.
> Thus, especially if you have a requirement for running proprietary
> code, it is key to do EL0 apps and/or stubdoms in Xen on ARM.
As you can see, we already discussed this :) Under "proprietary" I
have meant something like "open source, but not compatible with GPL",
and not it-is-so-secret-that-you-need-to-sign-100-NDAs. Anyways, this
is a hard topic and we need to consider it carefully.


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

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