[Barrelfish-users] about port barrelfish on tilera platform

[Simon Gerber]

Hi,

I'm not sure about which registers need to be loaded and which mode
the CPU should be has to be in, but "from" means the thread that is
being suspended (you can validate that by checking the call sites of
disp_switch -- lib/barrelfish/threads.c:604 and
lib/barrelfish/threads.c:833) and yes the ARM implementation of
disp_switch is buggy in the latest release. We've implemented a fix
but that commit hasn't made it into the public repository yet. I'm
attaching a patch.

-- Simon

On 30 November 2012 16:16, Robert Radkiewicz <rrad at kth.se> wrote:
> Moin,
>
> I have some follow-up questions for this, regarding
> lib/barrelfish/arch/<arch>/dispatch.c:
>
> - I guess the CPU should be in the user mode / protection level, since
> executing "resume" in exec.c. Is this function always called from the
> user mode?
> - Should *all* registers from register_state be loaded? Is the content
> of all registers arbitrary or can we have some assumptions (for example
> on the THREAD_REGISTER or lr)? In the moment, we're not sure how to load
> the program counter, after all other registers have a been restored,
> without destroying the content of one of these registers. The possible
> workaround for now would be to tell GCC to not use one register
> (-ffixed-reg), and use this. TilePro has enough registers...
> - In the x86 code you put registers into the __asm clobbered list. What
> is the purpose of this?
> - What is the intended order of the arguments from disp_switch()? If I'm
> not mistaken, x86 and ARM use different arguments to save to and load
> from. Does "from" mean, the thread we are switching from or the location
> to read the registers from?
>
> Regards,
> Robert
>
> On 19.11.2012 20:02, Andrew Baumann wrote:
>> Hi Robert,
>>
>> Start of day for userland is a pretty special environment on Barrelfish, and probably some of the toughest code to understand or port. The main thing you need to understand to make sense of it is the dispatch model: the crt0 code runs with the dispatcher "disabled", which means that it cannot take upcalls from the kernel. This in turn means that it cannot take a page fault, nor can it send or receive IDC messages, or use threading functionality such as mutexes. The normal printf() path uses IDC (e.g. to communicate with the serial driver), so it can't be called from this environment. Instead, the debugging facilities available boil down to a debugging system call sys_print(). You can see examples of this in lib/barrelfish/dispatcher.c for things like disp_assert_fail() etc. Also, beware that you have a very small stack at this point.
>>
>> Once you get onto a thread (i.e. once threads_init_disabled() completes and uses disp_resume() to start the thread) then most of these restrictions go away, and normal printf() calls should work.
>>
>> Hope this helps,
>> Andrew
>>
>
>
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: disp_switch.patch
Type: application/octet-stream
Size: 926 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20121130/029154f3/attachment.obj