On 09/17/2013 05:08 PM, Joel Sherrill wrote: > On 9/17/2013 9:51 AM, Rempel, Cynthia wrote: >>> ________________________________________ >>> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] >>> on behalf of Philipp Eppelt [philipp.epp...@mailbox.tu-dresden.de] >>> Sent: Tuesday, September 17, 2013 5:49 AM >>> To: rtems-devel@rtems.org >>> Subject: New configure option RTEMS_VIRTUAL >>> >> <snip> >>> The only satisfying way to compile the interrupt code dependent on >>> native or virtual environment is to introduce a configuration option >>> similar to RTEMS_SMP and RTEMS_MULTIPROCESSING: >>> >>> RTEMS_HYPERVISOR or RTEMS_VIRTUAL >>> >>> Other options: >>> :Introduce a new CPU target: >>> Besides i386 a new CPU i386-virtual could be introduced. This adds a lot >>> of duplicated code. The only difference would be 160 lines of code. >>> >>> >>> In the future this option can be used for other projects virtualizing >>> RTEMS on top of some hypervisor with any target CPU. >>> >>> >>> Do you have other ideas? >> Yes, option 3 could be to give the user the option of i386-virtual >> which would set the ax_rtems_virtual macro in configure.ac, so it >> would look like option 2 to the user and look like option 1 to the >> build-system... but if we're planning to have a virtual bsp for >> different architectures, we'd want to decide if option 3 is more >> desirable than option 1 or 2... > I expect we will end up with hypervisor support for multiple hypervisors > and on the x86, sparc, arm and powerpc architectures. > > I know there are unmerged hypervisor ports for the sparc and and pretty > sure for the arm on L4. > > If you change the target name, you need to ensure that the target name > change doesn't negatively impact tool name, target dependent configure > logic, etc. > > Part of this project was to lay the general groundwork as a pattern > for supporting other hypervisors on x86 and other architectures. > As is typically the case with RTEMS, the solution must be general. >>> What do you think about this? >> Could you provide links in your projects rtems wiki page to the 160 >> lines of code so a student making a virtual target for a different >> architecture would know where to start? >> Could you also document why inline functions were unsatisfactory? > One of the cases was interrupt disable/enable. They need to be inlined > for speed > and have to be virtualized with the hypervisor because (1) you don't > have permission > to do it in a virtual environment and (2) it may require special > handling by the > hypervisor. > > Some of the other cases I have seen are during context switches where > certain bits or registers are off limits when virtualized. > > Also the interrupt dispatching can be impacted. This is often on the BSP > side of the code tree so not as much of a problem but still not the same > virtual or real hardware. > > It's not the quantity of code in this case, it is the precision of what > differs and how it impacts performance and behavior. > > But I would like a full list. This is just from memory. The functions/files in question are documented here[0]. That's mainly code touching eflags via cli/sti or executing a hlt instruction. The code is referenced in the Implementation section of this page.
To keep this hypervisor independent there must be a call to the virtualization layer and no assumptions made about it. Although POK is not blocking these instruction (as far as I can see, didn't test it), other hypervisors, featuring a full vCPU abstraction like KVM or L4Re, will raise a GPF. @Inline: I remember chatting with Sebastian about it and inline functions were dismissed, but I can't remember why. Cheers, Philipp [0] http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#Questionable_parts _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
