[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] Implement qemu_thread_yield for posix, use
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [RFC PATCH] Implement qemu_thread_yield for posix, use it in mttcg to handle EXCP_YIELD |
Date: |
Wed, 22 Jan 2020 08:01:18 -1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
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~