Il 19/07/2013 08:38, Alex Bligh ha scritto:
>
> However, I still don't quite see how the poll in the mainloop is
> meant to exit when a timer expires. There's now no qemu_notify_event,
> and no SIGALRM, and the timeout will still be infinite (unless I
> calculate the timeout as the minimum across
Stefan,
--On 19 July 2013 09:58:50 +0800 Stefan Hajnoczi
wrote:
Options:
a) restore alarm timers (at least for the time being). Make all
alarm timers do qemu_notify_event. However, only run the AioContext
clock's timers within aio_poll. This is the least intrusive change.
b
Il 19/07/2013 03:58, Stefan Hajnoczi ha scritto:
>> Options:
>>
>> a) restore alarm timers (at least for the time being). Make all
>> alarm timers do qemu_notify_event. However, only run the AioContext
>> clock's timers within aio_poll. This is the least intrusive change.
>>
>> b) c
On Thu, Jul 18, 2013 at 07:48:28PM +0100, Alex Bligh wrote:
> Stefan,
>
> --On 17 July 2013 11:02:30 +0800 Stefan Hajnoczi wrote:
>
> >The steps to achieving this:
> >
> >1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout
> > instead for the main loop.
> >
> >2. Introduce a
Stefan,
--On 17 July 2013 11:02:30 +0800 Stefan Hajnoczi wrote:
The steps to achieving this:
1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout
instead for the main loop.
2. Introduce a per-AioContext aio_ctx_clock that can be used with
qemu_new_timer() to create a Q
Paolo,
--On 17 July 2013 10:11:07 +0200 Paolo Bonzini wrote:
The steps to achieving this:
1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout
instead for the main loop.
2. Introduce a per-AioContext aio_ctx_clock that can be used with
qemu_new_timer() to create a QEMU
Il 17/07/2013 10:07, Alex Bligh ha scritto:
> Stefan,
>
> --On 17 July 2013 11:02:30 +0800 Stefan Hajnoczi
> wrote:
>
>> The steps to achieving this:
>>
>> 1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout
>>instead for the main loop.
>>
>> 2. Introduce a per-AioContext a
Stefan,
--On 17 July 2013 11:02:30 +0800 Stefan Hajnoczi wrote:
The steps to achieving this:
1. Drop alarm timers from qemu-timer.c and calculate g_poll() timeout
instead for the main loop.
2. Introduce a per-AioContext aio_ctx_clock that can be used with
qemu_new_timer() to create a Q
Am 16.07.2013 um 18:55 hat Paolo Bonzini geschrieben:
> >> But I wouldn't introduce a
> >> new one-off concept (almost as much of a hack as idle BHs), I would
> >> rather reuse as much code as possible from QEMUTimer/QEMUClock. I must
> >> admit I don't have a clear idea of how the API would look
On Tue, Jul 16, 2013 at 10:24:38PM +0100, Alex Bligh wrote:
> --On 16 July 2013 18:55:15 +0200 Paolo Bonzini wrote:
>
> >>What do you think? In the end I thought the schedule_bh_at stuff
> >>was simpler.
> >
> >It is simpler, but I'm not sure it is the right API. Of course, if
> >Kevin and Stefa
Paolo,
--On 16 July 2013 18:55:15 +0200 Paolo Bonzini wrote:
What do you think? In the end I thought the schedule_bh_at stuff
was simpler.
It is simpler, but I'm not sure it is the right API. Of course, if
Kevin and Stefan says it is, I have no problem with that.
For the sake of having so
Il 16/07/2013 18:14, Alex Bligh ha scritto:
> Paolo,
>
>>> 3. aio_poll calls aio_bh_poll. If this returns true, this indicates
>>> at least one non-idle bh exists, which causes aio_poll not to
>>> block.
>>
>> No, this indicates that at least one scheduled non-idle bh exist*ed*,
>> which cause
Paolo,
3. aio_poll calls aio_bh_poll. If this returns true, this indicates
at least one non-idle bh exists, which causes aio_poll not to
block.
No, this indicates that at least one scheduled non-idle bh exist*ed*,
which causes aio_poll not to block (because some progress has been done).
Il 16/07/2013 17:29, Alex Bligh ha scritto:
> Paolo,
>
> --On 16 July 2013 09:34:20 +0200 Paolo Bonzini wrote:
>
You did. But aio_wait() ignores the timeout. It is only used by the
main loop.
>>>
>>> OK well that seems worth fixing in any case, as even without timed bh's
>>> that mea
Paolo,
--On 16 July 2013 09:34:20 +0200 Paolo Bonzini wrote:
You did. But aio_wait() ignores the timeout. It is only used by the
main loop.
OK well that seems worth fixing in any case, as even without timed bh's
that means no bh can be executed for an indeterminate time. I'll have
a look a
Il 16/07/2013 09:30, Alex Bligh ha scritto:
>
>> You did. But aio_wait() ignores the timeout. It is only used by the
>> main loop.
>
> OK well that seems worth fixing in any case, as even without timed bh's
> that means no bh can be executed for an indeterminate time. I'll have
> a look at that
Paolo,
--On 16 July 2013 08:16:42 +0200 Paolo Bonzini wrote:
You did. But aio_wait() ignores the timeout. It is only used by the
main loop.
OK well that seems worth fixing in any case, as even without timed bh's
that means no bh can be executed for an indeterminate time. I'll have
a look a
Il 16/07/2013 01:04, Alex Bligh ha scritto:
> Paolo,
>
> --On 15 July 2013 22:53:17 +0200 Paolo Bonzini wrote:
>
>> So far you are right.
>>
>> But this only happens if qemu_aio_wait() actually returns, so that on
>> the next call we poll for timers. If QEMU is stuck in qemu_aio_wait()'s
>> inf
Paolo,
--On 15 July 2013 22:53:17 +0200 Paolo Bonzini wrote:
So far you are right.
But this only happens if qemu_aio_wait() actually returns, so that on
the next call we poll for timers. If QEMU is stuck in qemu_aio_wait()'s
infinite-timeout poll(), it will never advance and process the time
Il 15/07/2013 22:15, Alex Bligh ha scritto:
> Paolo,
>
> --On 15 July 2013 16:25:01 +0200 Paolo Bonzini wrote:
>
> Thanks for the review.
>
>> Il 06/07/2013 18:24, Alex Bligh ha scritto:
>>> Add timed bottom halves. A timed bottom half is a bottom half that
>>> will not execute until a given ti
Paolo,
--On 15 July 2013 16:25:01 +0200 Paolo Bonzini wrote:
Thanks for the review.
Il 06/07/2013 18:24, Alex Bligh ha scritto:
Add timed bottom halves. A timed bottom half is a bottom half that
will not execute until a given time has passed (qemu_bh_schedule_at)
or a given interval has pass
Il 06/07/2013 18:24, Alex Bligh ha scritto:
> Add timed bottom halves. A timed bottom half is a bottom half that
> will not execute until a given time has passed (qemu_bh_schedule_at)
> or a given interval has passed (qemu_bh_schedule_in).
... and may be delayed arbitrarily past that given interva
--On 6 July 2013 17:24:57 +0100 Alex Bligh wrote:
Add timed bottom halves. A timed bottom half is a bottom half that
will not execute until a given time has passed (qemu_bh_schedule_at)
or a given interval has passed (qemu_bh_schedule_in). Any qemu
clock can be used, and times are specified in
Add timed bottom halves. A timed bottom half is a bottom half that
will not execute until a given time has passed (qemu_bh_schedule_at)
or a given interval has passed (qemu_bh_schedule_in). Any qemu
clock can be used, and times are specified in nanoseconds.
Timed bottom halves can be used where ti
24 matches
Mail list logo
