[PATCH] i386/virtualpok BSP, virtual BSP to be used with POK, build with enable-paravirt

[Philipp Eppelt]

On 01/10/2014 10:27 PM, Chris Johns wrote:
> Sorry about the delay. It is the holiday season here.
Happy Holidays :)
> 
> On 7/01/2014 9:14 pm, Philipp Eppelt wrote:
>> On 01/07/2014 04:25 AM, Chris Johns wrote:
>>> On 7/01/2014 12:18 pm, Joel Sherrill wrote:
>>>>
>>>> On 1/6/2014 5:14 PM, Chris Johns wrote:
>>>>> On 7/01/2014 4:24 am, Joel Sherrill wrote:
>>>>>> On 1/6/2014 11:13 AM, Philipp Eppelt wrote:
>>>>>>> Where are we on this?
>>>>>> I think I was OK on it. If Gedare is also, then it should be merged.
>>>>>>
>>>>> How will this change be tested on a regular basis ? As we move to
>>>>> constant integration testing we need a way to test this code.
>>>> Philipp.. can you provide us a "test plan"? That is, how you build and
>>>> test today
>>>> for what you have. I know that it is likely only a couple of tests at
>>>> this point
>>>> from an RTEMS perspective.
>>>>> I would like to understand how this extra dependency is tested and
>>>>> managed on an on going basis before getting my support.
>>>> Agreed. We need to be conscious of this.
>>>>
>>>> Is a test plan sufficient? We don't have the infrastructure
>>>> currently to
>>>> automate
>>>> testing this. I really hope Philipp enjoyed the project and will stay
>>>> involved and help
>>>> us grow this.
>>>
>>> Currently I do not know what I would need to run "Pok", can I build it
>>> from source and what is needed to do this ? Does Pok itself need special
>>> tools ?
>>>
>>> What development hosts does Pok support ?
>>
>> POK is short for Partitioned Operating system Kernel. It supports x86,
>> ppc and sparc. You can obtain the source here:
>> http://pok.safety-critical.net/pokdownload
>>
>> To build it on Debian you need:
>> GCC, binutils, perl, libxml-xpath-perl (the XML::XPath::XMLParser),
>> libxml-libxml-perl (the XML::LibXML Perl module), mtools (optional),
>> qemu, make.
>>
> 
> Do you need qemu to build it ?
No. Only as a test platform.
> 
>> For ppc and sparc you need to build the cross toolchain described here:
>> http://pok.safety-critical.net/wiki
> 
> Do you need those specific versions of GCC ? They look a little old.
> 
No, I used gcc 4.8.0.

> I see for the sparc is a sparc-elf target. I also see --with-newlib is
> present but the wiki page does not indicate a version or how this is
> handled.
I only followed these steps and it worked. I guess it just concerns the
files delivered together with gcc.

> 
>>
>>>
>>> If RTEMS is to offer a Pok based solution the project needs to address
>>> all these factors.
>>>
>>>> This is an important capability for the growth of RTEMS as a project.
>>>> We
>>>> need to
>>>> lay the groundwork so we can eventually test Pok, help it grow,  and
>>>> ensure
>>>> its stability. In a perfect world, it would have good test results
>>>> before we  test
>>>> Pok+RTEMS and put it through our acceptance tests.
>>>>
>>>
>>> I was not wishing to address acceptance tests. I am currently only
>>> concerned with patches entering RTEMS and knowing this code is being
>>> tested. As we move to constant integration we need to make sure the Pok
>>> component is maintained or we risk it rotting. I would rather have the
>>> commitment to support it addressed up front. I have no idea what this
>>> is.
>>
>> I don't have a script to build all this. If I update things in POK I
>> rebuild 'libpart.a' and copy it to RTEMS.
> 
> Why not use an installed version directly from pok ? I do not think
> adding binary blobs to RTEMS is a good idea.
To build POK you need to set an environment variable $POK_PATH. So you
could grab libpart.a from e.g.
$POK_PATH/examples/rtems_guest/generated-code/cpu/part1/libpart.a. But
the user must be made aware to change this path for his setup.

> 
>> This provides all information
>> for the interaction with POK to RTEMS.
> 
> Does this include headers ?
POK separates kernel and partition code. The kernel code is not affected
by the partitions running on top. And each partition has the 'knowledge'
of how to communicate with the kernel. libpart.a consits of this
communication code or 'partition base code' and the implementation of
the functions in virtualizationlayercpu.h and virtualizationlayerbsp.h.
Or what do you mean with headers?

> 
>> Then I just build the RTEMS
>> samples with --enable-paravirt for virtualpok and wait for it to fail at
>> the timertests (no timer implemented).
>> To execute the code, I need to copy for example hello.exe to a POK
>> program, place it in a partition and relink the POK binary to pull the
>> 'foreign' binary into POK's final system binary.
>> It's then tested with qemu.
> 
> That will be a interesting challenge to add into our testing framework.
> 
> Is the qemu the standard one or does pok have extra patches ?
No. Standard Qemu is used.

> 
>>
>> More details, but missing --enable-paravirt, here:
>> http://phipse.github.io/rtems/blog/2013/07/08/HelloWorld/
>>
>> Do you want to test if the code compiles or if it runs on the system?
> 
> I am looking a little further into the future and Joel has been clear
> that POK is important so we need to get the testing (compile and
> running) sorted and to manage its integration so it does not bitrot.
> This means RTEMS developers need easy access to POK, it tools and the
> ability to run it so we can do this. It might be POK is only built and
> tested on the RTEMS test hardware via buildbot when code is committed
> however we need to set this up and then maintain it.
> 
> As stated before my concern is constant integration and what it brings.
> The end objective is to have buildbot build and test all commits to a
> certain level. This level is still be determined and relates to the
> resources available and time it takes. Once working and after things
> settle we will start to remove the parts from RTEMS that are not being
> tested for cannot be tested. When the core team makes an RTEMS release
> we need to make be clear what works and what does not and if POK is not
> being built and being tested over time it will rot and then we would
> need to consider it for removal. It makes no sense to release code in
> RTEMS that does not build or has not been tested.
> 
>> You can shortcut the compile step, by providing a 'libpart.a' to copy
>> into virtualpok/. Then it's just configure and compile.
> 
> As a rule I tend not to like the coping of files into the tree. Could a
> path to pok be passed to configure with the --enable-paravirt option ?
> 
I would prefer a file in 'virtualpok' to set the path for libpart.a.
Because the Makefile in 'virtualpok' is the one checking for the
presence of 'libpart.a' and you don't need to reconfigure the if you
change the path.

>> The execution test needs all steps, including a version of POK
>> supporting this.
>> My development version can be found on github:
>> https://github.com/phipse/pok
>>
>> For more details on POK - including a what works and what doesn't - I
>> would write a wiki page.
>>
>>
>> Was this what you were looking for? Or did I miss the point?
>>
> 
> Yes it is and I think my understanding is becoming clearer.
> 
> I am wondering if the RSB should get a pok section.
RSB?