Maybe you're referring to switching between 64-bit and 32-bit code without going through EL1 first. This is explicitly documented as unsupported.

No, from memory it was an incorrect check the value passed to the kernel from userspace was wrong. I did make sure we have a check on signal return, however for it to work we need to check M[4] is set correctly. With this change the user could change this bit.

Considering that there is no need to split up this into two code paths for 32-bit/64-bit at least for what I'm trying to achieve, would you mind if I went ahead, committing this change as is? Once this change and D13148 land, I can work towards getting the sysent for cloudabi32 committed.

Kostik, I see there are also some places where we set td_retval from within cpu_set_upcall(). That should be unnecessary altogether, right? Even without this change, we don't end up calling cpu_set_syscall_retval() after thread creation....