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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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.

But they are not insecure. Also, in what cases they don't fit at all?


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

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.


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


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

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