<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 23, 2018 7:18 AM, "Sebastian Huber" <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">----- Am 23. Feb 2018 um 7:41 schrieb Chris Johns <a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>:<br>
<br>
> On 23/02/2018 14:15, Sebastian Huber wrote:<br>
>> ----- Am 22. Feb 2018 um 17:57 schrieb joel <a href="mailto:joel@rtems.org">joel@rtems.org</a>:<br>
>><br>
>>> On Thu, Feb 22, 2018 at 5:42 AM, Sebastian Huber <<br>
>>> <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
>>><br>
>>>> ----- Am 22. Feb 2018 um 6:06 schrieb Chris Johns <a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>:<br>
>>>><br>
>>>>> On 22/02/2018 13:37, Sebastian Huber wrote:<br>
>>>>>>><br>
>>>>>>> Architecture-specific names should use an ARCH_ or _Arch prefix and<br>
>>>> not CPU_ARCH<br>
>>>>>>> or _CPU_Arch.<br>
>>>>>>><br>
>>>>>>> This<br>
>>>>>>><br>
>>>>>>> CPU_DISABLE_INLINE_ISR_<wbr>DISABLE_ENABLE<br>
>>>>>>><br>
>>>>>>> is an architecture-specific implementation detail which doesn't<br>
>>>> propagate to<br>
>>>>>>> generic files, e.g. rtems/score/isrlevel.h, so it should not be<br>
>>>> introduced from<br>
>>>>>>> my point of view.<br>
>>>><br>
>>>> OK. I can add an architecture to the constant but my hope was that<br>
>>> isrlevel.h would eventually be where the cut off to the paravirtualized<br>
>>> ISR disable/enable methods would be made.<br>
>><br>
>> This RTEMS_PARAVIRT is a remnant of our failed attempt to upstream the XtratuM<br>
>> support for SPARC. For XtratuM on ARM, this didn't work, since here we needed<br>
>> different tweaks. I think that this paravirtualization is difficult to<br>
>> generalize. How many hypervisors do we support? Two? With a special header file<br>
>> we are less flexible and I think it will only complicate things.<br>
><br>
> Sorry, I am not following what you are saying. I am reading the above as either<br>
> provide a full generalisation or do not provide any framework. I suspect my<br>
> interpretation is wrong so could you please explain why a paravirt header makes<br>
> "things" more difficult?<br>
><br>
>> In the next hypervisor you will have some stuff in paravirt.h and then some more<br>
>> stuff somewhere else.<br>
><br>
> Yes I agree another will add other "stuff" "elsewhere" and this is all the more<br>
> reason to not spread RTEMS_PARAVIRT and to overload CPU specifics and I am<br>
> concerned adding this stuff to cpu.h is only going to create a mess for that<br>
> header if we get more hypervisors. I feel adding this to cpu.h is wrong because<br>
> this is nothing to do with *the* CPU and it's interface to RTEMS, it is all<br>
> about virtualising software that hosts RTEMS and how that effects the CPU.<br>
><br>
> All we should see in paravirt.h is the controls for _a_ hypervisor. The first to<br>
> do this work gets to add their stuff and others who come later may need to<br>
> refactor this header to support multiple hypervisors. I cannot say what that<br>
> means, there is nothing else on the table to consider but I hope there are more<br>
> to come. And it is fine if nothing else is ever supported.<br>
<br>
</div>Ok, but then could we please not introduce CPU_* defines in this paravirt.h.  The rationale for this header should be documented somewhere, maybe the general section of the CPU supplement. In one year nobody knows why we added this paravirt.h.<br>
<br>
The paravirt.h should be also added for sparc.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Agreed and I was going to file a ticket so whoever added stuff for the SPARC could follow the agreed upon pattern.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[...]<br>
<div class="quoted-text"><br>
>>> The need to compile with that option should have been documented.  As<br>
>>> the code is today, the definition of that register is only implied by<br>
>>> a GCC architectural revision. The register is indeed present in our<br>
>>> paravirtualized environment but we can't set it because it can't<br>
>>> be set in user mode. You already solved this problem and could<br>
>>> have even provided the helper routine for paravirtualized environments.<br>
>><br>
>> No, I don't think so. It is a workaround for a particular hypervisor<br>
>> implementation which has some particular shortcomings. With this workaround we<br>
>> violate the ABI.<br>
><br>
> Which ABI?<br>
<br>
</div>The ARM ABI. The ABI is defined by ARM and the platform. We currently use the GCC default platform definitions (e.g. Linux). Maybe we should use the TPIDRURW on RTEMS for the thread pointer. In this case, the hypervisor must add this register to the per-processor partition context. For XtratuM this was not an option<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Just to make sure we are all clear, I am dealing with a user space paravirtualized environment not a hypervisor. RTEMS is running in user mode. We can't write to that thread Id or disable interrupts. We access shared memory and other things by making calls to the host OS. Proceasing interrupts is abstracted through the host.  We ask the host to get information or request access to a hardware device. But mostly we have relied on "clients" to access native devices across the partition boundary.</div><div dir="auto"><br></div><div dir="auto">In this case, the host OS is Deos which is a DO178 Level A ARINC 653 RTOS. The goal is that Deos/ RTEMS will be conformant to the Open Group's FACE Technical Standard Safety Base profile. We are in the process of this now on the ARM, x86, and PowerPC.</div><div dir="auto"><br></div><div dir="auto">This combination works today with the FACE required support for some ARINC 653 APIs in the POSIX partition.</div><div dir="auto"><br></div><div dir="auto">I don't expect libdebugger to work in this environment and we will be using the native Deos partition aware debug setup. I spoke with Chris about disabling it. But it doesn't cause build issues so it is less intrusive to upstream to ignore it.</div><div dir="auto"><br></div><div dir="auto">There is a difference between paravirtualization for user space and running under a hypervisor which usually leaves the guest OS in supervisor mode. But as xstratum does, there may be some tweaks to be a guest.</div><div dir="auto"><br></div><div dir="auto">This wasn't a complaint. Just letting everyone know about our target environment and that it really works.</div><div dir="auto"><br></div><div dir="auto">My plan is to upstream everything possible and add documentation so folks understand. The Deos specific code isn't going to be submitted for multiple reasons.</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[...]<br>
</blockquote></div><br></div></div></div>