Yes, it looks like it. But I think for each architecture, we can share the most parts of the BSP and separate the hypervisor specifics.
I don't know much about virtualization on sparc/ppc/arm, so I can't say anything about these. Cheers Philipp On 09/23/2013 03:16 PM, Gedare Bloom wrote: > Sounds good. Would it be a BSP for each hypervisor for each target CPU > type the hypervisor runs on? > > -Gedare > > On Mon, Sep 23, 2013 at 9:10 AM, Philipp Eppelt > <[email protected]> wrote: >> Hi, >> >> in the last days I reused my work on L4RTEMS to do a quick and dirty >> test of the new virtualization layer. >> >> The implementation -which isn't working yet- showed, that we the >> i386/virtualpok BSP is a very good point to start, but the vCPU >> interface of L4Re brings it's own dependencies which must be added to >> include/ and in Makefile.am. >> I also had to extend the virtualizationalyerbsp.h file with these >> includes and a structure shared between L4Re and RTEMS. This struct >> accommodates a vCPU and console capability and a pointer to the vCPU >> state. They are filled in at start up by L4Re and can then be used by RTEMS. >> >> The take away are two things: >> First, we might end up with an own BSP for each hypervisor. >> Second, as far as I can see now, they only differ in aspects of the >> layer, not in the drivers using the layer. >> >> The code isn't on github yet, as I am short on time and have to sort >> things out first. The obstacle at the moment is to create a library in >> L4Re, which includes all L4Re dependencies and has only a few undefined >> references, which can be resolved by RTEMS. >> >> Cheers >> Philipp >> >> >> On 09/20/2013 09:22 AM, Philipp Eppelt wrote: >>> Hi, >>> >>> what did I do in my project? >>> >>> I designed and implemented a virtualization layer, which should ease the >>> virtualization of RTEMS across different hypervisors. >>> To test the layer and because of the ARINC 653 compliance POK was chosen >>> as a proof-of-concept host OS. >>> >>> The project was a partial success. The layer is designed, implemented >>> and a BSP is using it, and it is at least partially working. >>> I didn't succeed in changing POK so it can forward interrupts to >>> partitions reliably. But this is an POK related issue, which I think >>> won't be an issue on a host OS providing a vCPU abstraction. Also >>> implementing this for other architectures might be easier than for x86. >>> >>> A console is printing hello World and sometimes under some circumstances >>> the base_sp sample printed output, too. But the latter is not reliable. >>> >>> I have documented my efforts, including implementation issues, GDB traps >>> and where I left off on the wiki page [0]. >>> Also explanations on how to port the i386/virtualpok BSP to other >>> hypervisors and how to port this approach to other architectures can be >>> found there. The latter is pretty abstract, as I don't know much about >>> the other architectures(arm, ppc, sparc). >>> >>> I provide two patches: >>> * Split of the i386 CPU between score/cpu and libcpu. The interrupt >>> handling was moved to libcpu and two new CPU variants were introduced >>> there: Native and virtual. The native one works like before but the >>> virtual one calls the virtualization layer instead of executing cli,sti >>> or hlt. The list of affected functions is documented in the wiki[0]. >>> BUT: This patch won't be merged, as includes in cpukit from libcpu >>> aren't allowed (but it works). But before the discussion about a new >>> configuration option isn't finished and the option is implemented there >>> is no other way to achieve this. >>> >>> * A new i386 BSP is introduced: virtualpok. It is the corresponding BSP >>> to the virtual i386 CPU model and brings along the virtualization layer >>> as two header files in it's include/ directory. A console driver, clock >>> driver and IRQ management is implemented and as far as possible tested >>> on POK. >>> >>> >>> If you have questions on the work, I'd be happy to answer them. >>> >>> Cheers, >>> Philipp >>> >>> [0] >>> http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS >>> _______________________________________________ >>> rtems-devel mailing list >>> [email protected] >>> http://www.rtems.org/mailman/listinfo/rtems-devel >>> >> >> _______________________________________________ >> rtems-devel mailing list >> [email protected] >> http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
