Avi Kivity wrote:
Marcelo Tosatti wrote:
I'm worried about:
- boot guest using local apic timer
- reset
- boot with pit timer
- a zillion interrupts
So at the very least, we need a limiter.
Or have a new notifier on kvm_pic_reset, instead of simply acking one
pending irq? That seems the appropriate place to zero the counter.
Clearing the counter on reset is good, but it doesn't solve the
underlying problem, which is that there are two separate cases that
appear to the host as the same thing:
- guest masks irqs, does a lot of work, unmasks irqs
- host deschedules guest, does a lot of work, reschedules guest
Right now we assume any missed interrupts are due to host load. In
the reboot case, that's clearly wrong, but that is only an example.
Maybe we can use preempt notifiers to detect whether the timer tick
happened while the guest was scheduled or not.
It might get too complex. It can be done inside the vcpu_run function too:
An irq needs reinjection if the irq window was not open from the
timer tick till the next timer tick
minus the deschedule time. You also need to know on the right vcpu that
the pit irq it routed to.
Since scenarios like guests masking their pit and do a lot of work are
rare and a bad guest behaviour anyway,
I don't think we should special case them. So the pit reset hook is enough.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
