[Top][All Lists]

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

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

From: Alex Bennée
Subject: Re: [Qemu-devel] exec: Safe work in quiescent state
Date: Wed, 15 Jun 2016 15:51:26 +0100
User-agent: mu4e 0.9.17; emacs

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:
>> 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.

>> 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?

> - 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

  - 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.

>> - 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]