Thank you, now it is clear for me 

> The kernel differentiates between fault instruction and next instruction in 
> some cases. Might make more sense to just explain some different cases
> 
> * If a thread is interrupted by a hardware interrupt, then it should start 
> running again at the address of the next instruction that should be executed. 
> In this case the fault instruction is irrelevant, all the kernel will use is 
> the 'next instruction'. What this really means is the kernel will do nothing 
> to signal to the arch layer that the resume address should be modified. So on 
> architectures like arm (where we store LR) or x86 (where the hardware saves 
> NextIP) when we unstack the user context everything is correct. From the 
> non-arch side of the kernel the thread is always kept at ThreadState_Running, 
> and if you look in activateThread you will see this causes the thread to be 
> untouched when rescheduling it.
> 
> * If a thread does a syscall it is more complicated. The kernel may want to 
> start the thread running either at the instruction after the trap 
> instruction, if the syscall completed, or set it running back at the trap 
> instruction if the syscall needs to get restarted. This is where the fault 
> instruction comes in. In handleInvocation you will see if a check for 'if 
> (unlikely(status == EXCEPTION_PREEMPTED))', which if true results in 
> handleInvocation immediately returning. At the point it returns the thread 
> state is set to ThreadState_Restart, and if you look back in activateThread 
> you will see this results in setting the next instruction to 'getRestartPC', 
> which on arm is FaultInstruction. This means that when we resume this thread 
> it will immediately perform the trap instruction again (this is how the 
> kernel does pre-emption for long running operations). If that check for 
> EXCEPTION_PREEMPTED was false and all goes well with the invocation then the 
> 'setThreadState(thread, ThreadState_Running)' at the bottom of the function 
> gets called. This once again means that activateThread does nothing, and this 
> thread will start running at its next instruction, which is assumed to be the 
> instruction after the trap.
> 
> Other kinds of faults (vm faults etc) are a bit different in that it is the 
> user level fault handler that gets to pick the next instruction.
> 
> Adrian
> 
> On Sat 15-Oct-2016 11:02 PM, Vasily A. Sartakov wrote:
>>> we take address that causes syscall from the ksCurThread and set them back. 
>>> Thus, FaultInstruction should point to something different, right? 
>>> 
>>> 
>> I have add FaultInstruction in the same manner as it made in ARM platform: 
>> 
>>    sub lr, lr, #4
>> 
>>    /* Store FaultInstruction */
>>    str lr, [sp, #(PT_FaultInstruction - PT_LR_svc)]
>> 
>> I am tacking address of an instruction causes exception,  subtract 4 from 
>> the value, and save it into the FauiltInstruction. Now get* and set* 
>> functions are: 
>> 
>> 
>> word_t PURE
>> getRestartPC(tcb_t *thread)
>> {
>>    return getRegister(thread, FaultInstruction);
>> }
>> 
>> void
>> setNextPC(tcb_t *thread, word_t v)
>> {
>>    setRegister(thread, CP0_EPC, v);
>> }
>> 
>> Also, Faultinstruction is part of frameRegisters and Ā«linkedĀ» with cp0_epc 
>> of seL4_UserContext (sel4arch.xml) 
>> 
>> Now both tests are passed: 
>> 
>> Starting test 27: TEST_RECYCLE0001
>>  TEST_RECYCLE0001
>> Running test RECYCLE0001 (Basic endpoint recycle testing.)
>> <<seL4 [decodeInvocation/609 T0x8fee3f00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #101.>>
>> <<seL4 [decodeInvocation/609 T0x809a1500 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #163.>>
>> <<seL4 [decodeInvocation/609 T0x809a1700 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #230.>>
>> <<seL4 [decodeInvocation/609 T0x809a1900 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #303.>>
>> <<seL4 [decodeInvocation/609 T0x809a1b00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #364.>>
>> <<seL4 [decodeInvocation/609 T0x809db100 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #428.>>
>> <<seL4 [decodeInvocation/609 T0x809db300 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #491.>>
>> <<seL4 [decodeInvocation/609 T0x809db500 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #564.>>
>> <<seL4 [decodeInvocation/609 T0x809db700 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #619.>>
>> <<seL4 [decodeInvocation/609 T0x809db900 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #694.>>
>> <<seL4 [decodeInvocation/609 T0x809dbb00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #761.>>
>> <<seL4 [decodeInvocation/609 T0x809dbd00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #828.>>
>> <<seL4 [decodeInvocation/609 T0x809dbf00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #831.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29100 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #898.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29300 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #965.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29500 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1032.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29700 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1099.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29900 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1170.>>
>> <<seL4 [decodeInvocation/609 T0x8fe29b00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1221.>>
>> <<seL4 [decodeInvocation/609 T0x80a13100 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1295.>>
>> <<seL4 [decodeInvocation/609 T0x80a13300 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1354.>>
>> <<seL4 [decodeInvocation/609 T0x80a13500 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1427.>>
>> <<seL4 [decodeInvocation/609 T0x80a13700 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1490.>>
>> <<seL4 [decodeInvocation/609 T0x80a13900 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1563.>>
>> <<seL4 [decodeInvocation/609 T0x80a13b00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1628.>>
>> <<seL4 [decodeInvocation/609 T0x80a13d00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1635.>>
>> <<seL4 [decodeInvocation/609 T0x80a13f00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1698.>>
>> <<seL4 [decodeInvocation/609 T0x80aa1100 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1765.>>
>> <<seL4 [decodeInvocation/609 T0x80aa1300 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1828.>>
>> <<seL4 [decodeInvocation/609 T0x80aa1500 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1897.>>
>> <<seL4 [decodeInvocation/609 T0x80aa1700 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #1966.>>
>> <<seL4 [decodeInvocation/609 T0x80aa1b00 "child of: 'RECYCLE0001'" @40f9f8]: 
>> Attempted to invoke a null cap #2033.>>
>> Test RECYCLE0001 passed
>> Starting test 28: TEST_RECYCLE0002
>>  TEST_RECYCLE0002
>> Running test RECYCLE0002 (Recycle deletes caps)
>> <<seL4 [decodeInvocation/609 T0x809a1500 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #165.>>
>> <<seL4 [decodeInvocation/609 T0x809a1500 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #165.>>
>> <<seL4 [decodeInvocation/609 T0x809a1700 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #231.>>
>> <<seL4 [decodeInvocation/609 T0x809a1500 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #165.>>
>> <<seL4 [decodeInvocation/609 T0x809a1700 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #231.>>
>> <<seL4 [decodeInvocation/609 T0x809a1900 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #297.>>
>> <<seL4 [decodeInvocation/609 T0x809a1500 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #165.>>
>> <<seL4 [decodeInvocation/609 T0x809a1700 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #231.>>
>> <<seL4 [decodeInvocation/609 T0x809a1900 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #297.>>
>> <<seL4 [decodeInvocation/609 T0x809a1b00 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #361.>>
>> 
>> <<..>
>> 
>> <<seL4 [decodeInvocation/609 T0x80a90700 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #2003.>>
>> <<seL4 [decodeInvocation/609 T0x80a90900 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #2073.>>
>> <<seL4 [decodeInvocation/609 T0x80a90b00 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #2131.>>
>> <<seL4 [decodeInvocation/609 T0x80a90f00 "child of: 'RECYCLE0002'" @40f8b8]: 
>> Attempted to invoke a null cap #2203.>>
>> Test RECYCLE0002 passed
>> 
>> Can you please tell me something about the Faultinstruction context field, 
>> and, in general, what the assumptions about the behaviour of CPU you put 
>> into the design. For example, in MIPS, in a case of a trap, EPC points on 
>> instruction causes a trap, but in a case of an interrupt, PC and further EPC 
>> points on next instruction. Should I take this into the account somewhere in 
>> the kernel? 
>> 
>> 
>> 
>>>> Hope that helps.
>>>> 
>>>> Regards,
>>>> Hesham
>>>> ________________________________________
>>>> From: Devel 
>>>> <devel-bounces@sel4.systems> on behalf of Vasily A.Sartakov 
>>>> <sarta...@ksyslabs.org>
>>>> 
>>>> Sent: Friday, October 14, 2016 12:33 AM
>>>> To: 
>>>> devel@sel4.systems
>>>> 
>>>> Subject: [seL4] endpoint.c
>>>> 
>>>> Hello.
>>>> 
>>>> I have a problem with endpoint.c test (RECYCLE0001):
>>>> 
>>>> Error: seL4_MessageInfo_get_label(tag) == seL4_InvalidCapability at line 
>>>> 50 of file /long/path/apps/sel4test-tests/src/tests/endpoints.c
>>>> 
>>>> I am reading MR(0) in call_func above this check  and see, that seL4_Call 
>>>> returns values that were sent before. For example, 100 for the first 
>>>> thread, 101 for the second and etc. Thus, as far I understand, 
>>>> cnode_recycle does not work at all. I am pretty sure that my seL4_Call 
>>>> syscall was implemented properly. I have looked inside the kernel, and 
>>>> tried to track everything related to cteRecycle and do not see anything 
>>>> platform specific. I know that it is a complicated question, but any ideas 
>>>> or hints where to look?


-- 
Vasily A. Sartakov
sarta...@ksyslabs.org





_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Reply via email to