Re: It's BeOS, it's the OS
The issue with x86 is which code can access the I/O instructions and physical memory directly - most hardware usually use a combination of the two - being mapped to some I/O ports and physical addresses.
You can move both accesses up to userland, but then you lose some hardware security - the CPU itself won't allow user code to run those instruction or access that memory - and you need to deploy other security mechanism.
Anyway, even with multiple cores the issue is when a thread needs a ring transition - the required checks and call setting up require CPU cycles (even if they've been reduced by the SYSCALL/SYSENTER opcodes) - execution might not be passed to another thread on another core.
Your model would be message based - split the CPU between cores executing kernel and core executing user code - and pass messages between them. It could be less versatile if you don't know workloads in advance.