qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 03/50] cpu: introduce cpu_in_exclusive_work_c


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v3 03/50] cpu: introduce cpu_in_exclusive_work_context()
Date: Thu, 20 Jun 2019 10:50:26 +0100
User-agent: mu4e 1.3.2; emacs 26.1

Richard Henderson <address@hidden> writes:

> On 6/14/19 10:11 AM, Alex Bennée wrote:
>>              start_exclusive();
>> +            cpu->in_exclusive_work_context = true;
>>              wi->func(cpu, wi->data);
>> +            cpu->in_exclusive_work_context = false;
>>              end_exclusive();
>
> Is there a reason not to put those into start/end_exclusive?

Not particularly... it can use current_cpu to find the cpu and set the
flag.

> And if not, what does in_exclusive_work_context mean?

Currently the check implies it's only for:

 exclusive work context, which has previously been queued via 
async_safe_run_on_cpu()

which avoids jumping through hoops if another async_safe tasks still
wants to flush the TB. However keeping it with start/end exclusive means
we could also clean up the code in:

  void cpu_exec_step_atomic(CPUState *cpu)
  {
    ..
    /* volatile because we modify it between setjmp and longjmp */
    volatile bool in_exclusive_region = false;
    ..
    if (sigsetjmp(cpu->jmp_env, 0) == 0) {
        start_exclusive();
        ..
    } else {
        ..
    }

    if (in_exclusive_region) {
        ..
        end_exclusive();

but the volatile makes me nervous. Is it only a risk that local
variable accesses might get optimised away?

>
>
> r~


--
Alex Bennée



reply via email to

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