pussuw commented on pull request #5782: URL: https://github.com/apache/incubator-nuttx/pull/5782#issuecomment-1076670069
Thank you for your comments. Here are a few considerations to your questions. >How about we trigger software interrupt(SSIP) instead ECALL? This mechanism could maybe be used, but is not necessary, as the asm functions provided here do the same. Also, the SW interrupt is typically used for inter-processor communication (IPI) and I would like to keep that option open for a true SMP. > Can we fake CPU by modifying CSR_STATUS to match the ECALL condition and ghen jump to exception_common directly? Not really, in my opinion this gets extremely complicated. 1. Sharing the IRQ stack will break this 2. I don't know how the mcause/scause registers will behave in this case. Are these even writable (need to check tomorrow, I don't think so). The final thing is the CURRENT_REGS behavior, CURRENT_REGS != NULL is tested in many places to guess whether the SW is in IRQ or not > It's different from the active context switch, the passive context switch(e.g. the block thread wake up by an interrupt handler) since the interrupt handle already run in S-mode: > The exception entry pointer already save the current thread context for us so we can restore the unblock thread context directly without trap to M-mode Absolutely true, and this is what is done in this implementation also >My understanding is different from yours: user task need issue syscall here otherwise how the thread can raise the privilege to S-mode? This is also true. The user thread must use syscall to raise privilege to S-mode / kernel mode. But a context switch syscall is never sent by the application directly from **user mode**. This happens only when the user task is already executing kernel code in privileged mode. How the task got there can happen e.g. via sem_wait() or some other synchronization mechanism / timer interrupt / other interrupt etc. In any case, at this point the user task is already in **privileged mode**, and thus any sys_call() (including SYS_switch_context) will be executed from privileged mode. If that uses ecall, then the privilege will raise from S->M which is not what we want. > No, all syscalls(either reserved or normal) are for user space(U-mode) to initiate the designed functionality to kernel space. Also true. But with the old implementation the user task can / is already in kernel space, when e.g. sys_call(SYS_context_switch) is executed. If sys_call executes ecall instruction, again we raise privilege from S->M (or M->M in the case of the flat build). This is the case for many (not all, like I said, sorry about that) reserved syscalls. >The suggestion look reasonable, sys_call0-6 is directly called by user space code, libc/machine is a better place. But, we can do the change for all arch in a new patch. I agree, a new patch is better for this. This patch is already very big. And I still have the CONFIG_BUILD_KERNEL code to give for review (it's also done) :) On a last note, I think I chose the naming of "ksys_call()" quite poorly. Actually, the function is just a trampoline to execute the asm function riscv_syscall_dispatch. A trampoline is required to store the original return address, so the "ksys_call()" return procedure will know where it came from originally (like with ecall you know from EPC, but emulated with SW!) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
