New configure option RTEMS_VIRTUAL

[Philipp Eppelt]

On 09/17/2013 05:08 PM, Joel Sherrill wrote:
> On 9/17/2013 9:51 AM, Rempel, Cynthia wrote:
>>> ________________________________________
>>> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org]
>>> on behalf of Philipp Eppelt [philipp.eppelt at mailbox.tu-dresden.de]
>>> Sent: Tuesday, September 17, 2013 5:49 AM
>>> To: rtems-devel at 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