On 01/05/2010 06:48 AM, Paolo Bonzini wrote:
On 01/05/2010 12:59 AM, Anthony Liguori wrote:
When I think of a main loop, I think of something that provides the
following three services
1) fd based events
2) time based events
3) an idle callback
The problem we have is that bottom halves aren't quite idle callbacks.
They have some really weird properties about the guarantees of when
they're executed. At any rate, you really cannot express a time based
event as an idle callback because you need to setup the select() timeout
based on the next deadline and then dispatch timer event based on
selects return. idle functions have none of this ability.
I see bottom halves as a fourth service, providing the ability to
synchronize stuff that needs to execute in a particular thread
(guaranteeing thread-safety and especially signal-safety).
Thread and signal safety are slightly different. Scheduling an idle
callback from a signal handler is a pretty reasonable thing to do.
Executing no a different thread is a whole different matter. Right now,
we really use bottom halves to run something on the io thread and have a
different mechanism that ran on a specific thread. Right now, we mix
that between bottom halves and on_vcpu.
In some sense, the problem is that bottom halves conflate this service
_and_ idle callbacks, and that is the weird property. Idle callbacks
are used basically only for DMA, and real-world DMA does not have at
all the semantics that qemu_bh_schedule_idle provides (which in turn
is very tricky and not exactly what comments in qemu_bh_update_timeout
promise).
I think before we can do any major surgery, we need to redo the way that
legacy DMA is handled so that it doesn't require constant polling as it
does now.
Regards,
Anthony Liguori
