Re: [Qemu-devel] [RFC PATCH V2 2/3] cpus: add a tcg_executing flag.

[Peter Maydell]

On 13 July 2015 at 16:56, Alex Bennée <address@hidden> wrote:
>> From: KONRAD Frederic <address@hidden>
>> @@ -322,6 +323,8 @@ struct CPUState {
>>         (absolute value) offset as small as possible.  This reduces code
>>         size, especially for hosts without large memory offsets.  */
>>      volatile sig_atomic_t tcg_exit_req;
>> +
>> +    volatile int tcg_executing;
>
> My concern is on weakly ordered backends is volatile enough for this
> flag or do we need some sort of memory barrier when we update it? Does
> it just introduce an inefficiency that other threads may spin a few
> times waiting to find out the vCPU has halted?

Plus "volatile int" is a bit of an "is this really right?" red flag...
Currently in QEMU we use 'volatile' for:
 (1) "volatile sig_atomic_t", which is dealing with variables
     accessed from signal handlers
 (2) marking local variables which mustn't be trashed by longjmp()
 (3) some things in tests/ code which I'm ignoring because they're
     only test code
 (4) a few other things which are suspicious at best:
  hw/intc/apic_common.c:    volatile int a_i_d = apic_irq_delivered;
  hw/xen/xen_pt_msi.c:        const volatile uint32_t *vec_ctrl;
  trace/simple.c:static volatile gint trace_idx;
  trace/simple.c:static volatile gint dropped_events;

and I would be very dubious about adding more direct uses of volatile.
You almost certainly want something from atomic.h instead.

thanks
-- PMM