On 1/21/20 5:26 PM, David Gibson wrote: > However, a more common use of qemu is the "pseries" machine type, > which emulates only a guest (in the cpu architectural sense) with qemu > taking the place of the hypervisor as well as emulating the cpus. In > that case the H_CONFER hypercall goes to qemu. > >> If you are running QEMU as a KVM monitor this is still outside of it's >> scope as all the scheduling shenanigans are dealt with inside the >> kernel. >> >> From QEMU's TCG point of view we want to concern ourselves with what the >> real hardware would do - which I think in this case is drop to the >> hypervisor and let it sort it out. > > Right, but with the "pseries" machine type qemu *is* the hypervisor.
In which case this behaviour doesn't seem implausible. I will note that "pthread_yield" isn't standardized; "sched_yield" is the one in POSIX. Though that says nothing about how that syscall might affect a hypothetical many-to-one pthread implementation. You could, I suppose, have a configure test for pthread_yield. Also, the win32 implementation would be SwitchToThread(): https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-switchtothread It looks like one need do nothing for the single-threaded implementation, qemu_tcg_rr_cpu_thread_fn, as any return to the main loop will select the next round-robin cpu. But a note to say that's been tested would be nice. r~
