qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] exec: Safe work in quiescent state


From: alvise rigo
Subject: Re: [Qemu-devel] exec: Safe work in quiescent state
Date: Wed, 15 Jun 2016 17:25:18 +0200

On Wed, Jun 15, 2016 at 4:51 PM, Alex Bennée <address@hidden> wrote:
>
> alvise rigo <address@hidden> writes:
>
>> Hi Sergey,
>>
>> Nice review of the implementations we have so far.
>> Just few comments below.
>>
>> On Wed, Jun 15, 2016 at 2:59 PM, Sergey Fedorov <address@hidden> wrote:
>>> On 10/06/16 00:51, Sergey Fedorov wrote:
>>>> For certain kinds of tasks we might need a quiescent state to perform an
>>>> operation safely. Quiescent state means no CPU thread executing, and
>>>> probably BQL held as well. The tasks could include:
> <snip>
>>>
>>> Alvise's async_wait_run_on_cpu() [3]:
>>> - uses the same queue as async_run_on_cpu();
>>> - the CPU that requested the job is recorded in qemu_work_item;
>>> - each CPU has a counter of such jobs it has requested;
>>> - the counter is decremented upon job completion;
>>> - only the target CPU is forced to exit the execution loop, i.e. the job
>>> is not run in quiescent state;
>>
>> async_wait_run_on_cpu() kicks the target VCPU before calling
>> cpu_exit() on the current VCPU, so all the VCPUs are forced to exit.
>> Moreover, the current VCPU waits for all the tasks to be completed.
>
> The effect of qemu_cpu_kick() for TCG is effectively just doing a
> cpu_exit() anyway. Once done any TCG code will exit on it's next
> intra-block transition.
>
>>
> <snip>
>>> Distilling the requirements, safe work mechanism should:
>>> - support both system and user-mode emulation;
>>> - allow to schedule an asynchronous operation to be performed out of CPU
>>> execution loop;
>>> - guarantee that all CPUs are out of execution loop before the operation
>>> can begin;
>>
>> This requirement is probably not necessary if we need to query TLB
>> flushes to other VCPUs, since every VCPU will flush its own TLB.
>> For this reason we probably need to mechanisms:
>> - The first allows a VCPU to query a job to all the others and wait
>> for all of them to be done (like for global TLB flush)
>
> Do we need to wait?

Yes, otherwise the instruction (like MCR which allows to do TLB
invalidation) is not completely emulated before executing the
following one.
During the LL emulation is also required since it avoids possible race
conditions.

>
>> - The second allows a VCPU to perform a task in quiescent state i.e.
>> the task starts and finishes when all VCPUs are out of the execution
>> loop (translation buffer flush)
>
> If you really want to ensure everything is done then you can exit the
> block early. To get the sort of dsb() flush semantics mentioned you
> simply:
>
>   - queue your async safe work
>   - exit block on dsb()
>
>   This ensures by the time the TCG thread restarts for the next
>   instruction all pending work has been flushed.
>
>> Does this make sense?
>
> I think we want one way of doing things for anything that is Cross CPU
> and requires a degree of synchronisation. If it ends up being too
> expensive then we can look at more efficient special casing solutions.

OK, I agree that we should start with an approach that fits the two use cases.

Thank you,
alvise

>
>>
>>> - guarantee that no CPU enters execution loop before all the scheduled
>>> operations are complete.
>>
>> This is probably too much in some cases for the reasons of before.
>>
>> Best regards,
>> alvise
>>
>>>
>>> If that sounds like a sane approach, I'll come up with a more specific
>>> solution to discuss. The solution could be merged into v2.7 along with
>>> safe translation buffer flush in user-mode as an actual use case. Safe
>>> cross-CPU TLB flush would become a part of MTTCG work. Comments,
>>> suggestions, arguments etc. are welcome!
>>>
>>> [1] http://thread.gmane.org/gmane.comp.emulators.qemu/355323/focus=355632
>>> [2] http://thread.gmane.org/gmane.comp.emulators.qemu/407030/focus=407039
>>> [3] http://thread.gmane.org/gmane.comp.emulators.qemu/413978/focus=413982
>>> [4] http://thread.gmane.org/gmane.comp.emulators.qemu/356765/focus=356789
>>> [5] http://thread.gmane.org/gmane.comp.emulators.qemu/397295/focus=397301
>>> [6] http://thread.gmane.org/gmane.comp.emulators.qemu/413978/focus=417231
>>>
>>> Kind regards,
>>> Sergey
>
>
> --
> Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]