On Tue, Aug 6, 2013 at 5:30 PM, Stefan Hajnoczi wrote:
> On Mon, Aug 05, 2013 at 03:33:24PM +0800, Liu Ping Fan wrote:
>> diff --git a/cpus.c b/cpus.c
>> index 85e743d..ab92db9 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -107,12 +107,17 @@ static int64_t qemu_icount;
>> typedef struct TimersStat
On Mon, Aug 05, 2013 at 03:33:24PM +0800, Liu Ping Fan wrote:
> diff --git a/cpus.c b/cpus.c
> index 85e743d..ab92db9 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -107,12 +107,17 @@ static int64_t qemu_icount;
> typedef struct TimersState {
> int64_t cpu_ticks_prev;
> int64_t cpu_ticks_offs
On 08/06/2013 07:58 AM, liu ping fan wrote:
On Mon, Aug 5, 2013 at 9:29 PM, Paolo Bonzini wrote:
In kvm mode, vm_clock may be read outside BQL.
Not just in KVM mode (we will be able to use dataplane with TCG sooner
or later), actually.
Oh. But this patch does not fix cpu_get_icount()'s th
On Mon, Aug 5, 2013 at 9:29 PM, Paolo Bonzini wrote:
>
>> In kvm mode, vm_clock may be read outside BQL.
>
> Not just in KVM mode (we will be able to use dataplane with TCG sooner
> or later), actually.
>
Oh. But this patch does not fix cpu_get_icount()'s thread-safe issue.
So currently, could I j
> In kvm mode, vm_clock may be read outside BQL.
Not just in KVM mode (we will be able to use dataplane with TCG sooner
or later), actually.
Otherwise looks good!
Paolo
> This will make
> timers_state --the foundation of vm_clock exposed to race condition.
> Using private lock to protect it.
>
