On Fri, Aug 2, 2013 at 10:43 PM, Stefan Hajnoczi wrote:
> On Fri, Aug 02, 2013 at 11:33:40AM +0800, liu ping fan wrote:
>> On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh wrote:
>> > Paolo,
>> >
>> >
>> > --On 1 August 2013 08:19:34 -0400 Paolo Bonzini
>> > wrote:
>> >
>> >>> > True, qemu_event basi
On Fri, Aug 02, 2013 at 11:33:40AM +0800, liu ping fan wrote:
> On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh wrote:
> > Paolo,
> >
> >
> > --On 1 August 2013 08:19:34 -0400 Paolo Bonzini wrote:
> >
> >>> > True, qemu_event basically works only when a single thread resets it.
> >>> > But there is no
On Aug 02 2013, liu ping fan wrote:
> On Thu, Aug 1, 2013 at 10:28 PM, Paolo Bonzini wrote:
> > > > > > So actually there is another problem with this patch (both the
> > > > > > condvar and the event approach are equally buggy). If a timer
> > > > > > on clock X disables clock X, qemu_clock_ena
On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh wrote:
> Paolo,
>
>
> --On 1 August 2013 08:19:34 -0400 Paolo Bonzini wrote:
>
>>> > True, qemu_event basically works only when a single thread resets it.
>>> > But there is no race condition here because qemu_run_timers cannot be
>>> > executed concurre
On Thu, Aug 1, 2013 at 10:28 PM, Paolo Bonzini wrote:
> On Aug 01 2013, Alex Bligh wrote:
>> Paolo,
>>
>> --On 1 August 2013 15:51:11 +0200 Paolo Bonzini wrote:
>>
>> >>> So actually there is another problem with this patch (both the
>> >>> condvar and the event approach are equally buggy). If
On Aug 01 2013, Alex Bligh wrote:
> Paolo,
>
> --On 1 August 2013 15:51:11 +0200 Paolo Bonzini wrote:
>
> >>> So actually there is another problem with this patch (both the
> >>> condvar and the event approach are equally buggy). If a timer
> >>> on clock X disables clock X, qemu_clock_enable
Paolo,
--On 1 August 2013 15:51:11 +0200 Paolo Bonzini wrote:
> So actually there is another problem with this patch (both the
> condvar and the event approach are equally buggy). If a timer
> on clock X disables clock X, qemu_clock_enable will deadlock.
Yes. I believe there will be a simila
On Aug 01 2013, Alex Bligh wrote:
> >So actually there is another problem with this patch (both the
> >condvar and the event approach are equally buggy). If a timer
> >on clock X disables clock X, qemu_clock_enable will deadlock.
>
> Yes. I believe there will be a similar problem if a timer
> cre
Paolo,
--On 1 August 2013 08:19:34 -0400 Paolo Bonzini wrote:
> True, qemu_event basically works only when a single thread resets it.
> But there is no race condition here because qemu_run_timers cannot be
> executed concurrently by multiple threads (like aio_poll in your
> bottom half patches
> > True, qemu_event basically works only when a single thread resets it. But
> > there is no race condition here because qemu_run_timers cannot be executed
> > concurrently by multiple threads (like aio_poll in your bottom half
> > patches).
>
> ... or, if rebasing on top of my patches, qemu_run
--On 1 August 2013 04:57:52 -0400 Paolo Bonzini wrote:
True, qemu_event basically works only when a single thread resets it. But
there is no race condition here because qemu_run_timers cannot be executed
concurrently by multiple threads (like aio_poll in your bottom half
patches).
... or,
> > Hmm, do we even need clock->using at this point? For example:
> >
> >qemu_clock_enable()
> >{
> >clock->enabled = enabled;
> >...
> >if (!enabled) {
> >/* If another thread is within qemu_run_timers,
> > * wait for it to finish.
> >
On Tue, Jul 30, 2013 at 5:17 PM, Paolo Bonzini wrote:
> Il 30/07/2013 04:42, liu ping fan ha scritto:
>> On Mon, Jul 29, 2013 at 7:21 PM, Paolo Bonzini wrote:
>>> Il 29/07/2013 10:10, liu ping fan ha scritto:
On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote:
> Il 29/07/2013 05:16, L
Il 30/07/2013 11:51, Alex Bligh ha scritto:
> As far as walking the QEMUTimerList itself is concerned, this is
> something which is 99.999% done by the thread owning the AioContext.
> qemu_clock_enable should not even be walking this list. So I don't
> see why the protection here is needed.
The pr
Paolo,
--On 30 July 2013 11:17:05 +0200 Paolo Bonzini wrote:
Hmm, do we even need clock->using at this point? For example:
qemu_clock_enable()
{
clock->enabled = enabled;
...
if (!enabled) {
/* If another thread is within qemu_run_timers,
* w
Il 30/07/2013 04:42, liu ping fan ha scritto:
> On Mon, Jul 29, 2013 at 7:21 PM, Paolo Bonzini wrote:
>> Il 29/07/2013 10:10, liu ping fan ha scritto:
>>> On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote:
Il 29/07/2013 05:16, Liu Ping Fan ha scritto:
> After disabling the QemuClock,
On Mon, Jul 29, 2013 at 7:21 PM, Paolo Bonzini wrote:
> Il 29/07/2013 10:10, liu ping fan ha scritto:
>> On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote:
>>> Il 29/07/2013 05:16, Liu Ping Fan ha scritto:
After disabling the QemuClock, we should make sure that no QemuTimers
are stil
Il 29/07/2013 10:10, liu ping fan ha scritto:
> On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote:
>> Il 29/07/2013 05:16, Liu Ping Fan ha scritto:
>>> After disabling the QemuClock, we should make sure that no QemuTimers
>>> are still in flight. To implement that, the caller of disabling will
On Mon, Jul 29, 2013 at 2:30 PM, Paolo Bonzini wrote:
> Il 29/07/2013 05:16, Liu Ping Fan ha scritto:
>> After disabling the QemuClock, we should make sure that no QemuTimers
>> are still in flight. To implement that, the caller of disabling will
>> wait until the last user's exit.
>>
>> Note, the
Il 29/07/2013 05:16, Liu Ping Fan ha scritto:
> After disabling the QemuClock, we should make sure that no QemuTimers
> are still in flight. To implement that, the caller of disabling will
> wait until the last user's exit.
>
> Note, the callers of qemu_clock_enable() should be sync by themselves,
After disabling the QemuClock, we should make sure that no QemuTimers
are still in flight. To implement that, the caller of disabling will
wait until the last user's exit.
Note, the callers of qemu_clock_enable() should be sync by themselves,
not protected by this patch.
Signed-off-by: Liu Ping F
21 matches
Mail list logo
