On 06/09/2010 11:24 PM, Avi Kivity wrote:
On 06/10/2010 12:17 AM, Zachary Amsden wrote:
On 06/09/2010 03:23 AM, Marcelo Tosatti wrote:
On Tue, Jun 08, 2010 at 04:36:16PM -1000, Zachary Amsden wrote:
+ pt->timer.function = pit_timer_fn;
I am happy to see this. I thought kvm_timer_fn was a step
backwards; it was too general of a function to justify the savings
of 20 some odd lines of code.
This was not done to save 20 lines of code:
http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg18640.html
Is there any chance that using a workqueue might help the problem of
hrtimers firing too quickly? I wanted to return HR_NORESTART from
pit_timer_fn always, then restart the hrtimer on delivery, but
because of unreliable delivery, it wasn't clear how to do that.
Perhaps the workqueue can be used to restart the timer instead,
avoiding problems of impossibly small timeouts causing hrtimers to
run amok.
It should be rearmed on ACK ideally. How come delivery is unreliable?
Due to the various ways IRQ can be latched or not with different
routing. If you program a very short timeout, it should fire even if
the guest is slow to respond:
i..i..i..i..i..i..i
..a...a...a...a
if you don't restart right away, only on ack, you can risk the refire
of the interrupt getting lost, especially if the guest happens to
reprogram the PIT while this is happening...
Restarting on ack has the big advantage of not rearming at all if the
guest doesn't ack, i.e. a timer left running talking to a masked irq pin.
Exactly... it scales too, with how fast we can manage to deliver the
interrupts. We just have to be sure we don't drop the re-fire
completely in any race conditions. Some stress will be required.
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
