Hmm, not sure I agree. In the case of OS threads, the kernel will preempt a misbehaving thread and give the CPU to another thread according to priority. In the case where a virtual thread enters an infinite loop however there is no way for the virtual thread scheduler to do the same, unless kernel interruptions of the stuck host OS thread somehow return control to the virtual thread scheduler instead of whatever code was executing when the host thread was preempted. It's not clear to me this is really feasible though.
Yes, it's definitely possible that a spinning virtual thread will effectively pin the current OS thread. The Loom folks could keep, say, a count of how many instructions the virtual thread has executed, and pre-empt it itself if it needs to. This could fight a little with the OS scheduler, so I'm not sure what the tradeoffs are, but if you absolutely cannot allow a spinning virtual thread to effectively pin an OS thread, you'd want to do this.
If you're going to do a bunch of computation without blocking, I'm not sure virtual threads are the tool you want to apply in the first place. They're meant to provide cheap blocking and cheap context switching. If you've got a job that's more CPU-bound than I/O bound, it's probably worth using OS threads instead.
