> There's a very simple solution here. Don't schedule two threads with different trust domains on different SMT threads on the same core. A single thread alrea

> There's a very simple solution here. Don't schedule two threads with different trust domains on different SMT threads on the same core. A single thread already has two different trust domains (user mode and kernel mode), so any pair of threads will have different trust domains when one of them is running a system call or an interrupt. So this solution would also have to either pause the SMT sibling while entering the kernel, or run the kernel code in a separate core (an idea like this was briefly suggested on the RISC-V isa-dev mailing list a few months ago: to have a separate core which handles interrupts and kernel mode for a group of user-mode-only cores).