x86 interpreter and NOVA hypervisor - Was: [PATCH] do_it

[Gedare Bloom]

On Mon, Oct 20, 2014 at 10:55 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Gedare and others,
>
> On Sunday 19 of October 2014 15:01:08 Gedare Bloom wrote:
>> On Sun, Oct 19, 2014 at 7:48 AM, Pavel Pisa <pisa at control.felk.cvut.cz>
> ...
>> >    set interpreter in RTEMS which would allow to run BIOS x86
>> >    real code sandboxed and with additional memory ranges protection
>> >    and with minimal impact on other RT code running in parallel.
>> >    This would be nice to do, allows to use x86 PCI VESA BIOS cards
>> >    on other PCI enabled architectures but it is above our current
>> >    capabilities and time constraints. On the other hand we can provide
>> >    example from NOVA microkernel which achieved and uses this goal.
>>
>> This last option seems quite interesting. Can you link to the example
>> or any doc on how it is done?
>
> The x86 interpreter used for BIOS, VBE and other untrusted HW related
> code indirect execution is part of NOVA hypervisor. The source code
> of the executor is there
>
>  https://github.com/TUD-OS/seoul/tree/master/executor
>
> The executor is written in C++ and significant part of source
> code for x86 instruction decoding is build with use of python
> script and GNU binutils.
>
> The code is GPL licensed but there is some chance to negotiate
> RTEMS required exception. My colleague - Michal Sojka - has
> worked with these people and have contact to them.
>
> As for the related hypervisor and kernel project, it would
> be interresting to combine RTEMS and NOVA hypervisor
> http://hypervisor.org/ for some kinds of applications.
> My colleague looks for some research project which would
> allow to cooperate on porting NOVA to ARM/AArch64 and or
> to combine NOVA with RTEMS. RTEMS porting to AArch 64
> would be interresting for me as well. But these are kinds
> of projects which we cannot start from enthusiasm only.
> They require funding - i.e. larger research project, consortium,
> strong company contract etc. to pay required man years of work.
>
Thanks Pavel, perhaps any of these could make decent GSoC if we get in
again. The paravirtualization of RTEMS slowly moves toward a steady
staet I feel, but there are lingering problems with the bsp-centric
nature of RTEMS that make the existing solutions less than
satisfactory to me. (All proposals so far require linking some blob
for the hypercall interface. We should perhaps invest in something
else like pvops.)

Are there good boards for aarch64 that motivate using RTEMS on it?

-Gedare

> Best wishes,
>
>                Pavel
>