From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [PATCH 3/3] KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked Date: Tue, 06 Jan 2009 11:35:16 +0200 Message-ID: <496325D4.2090101@redhat.com> References: <1231085685-32201-1-git-send-email-avi@redhat.com> <1231085685-32201-4-git-send-email-avi@redhat.com> <20090105183159.GC5592@amt.cnet> <49627495.9020203@redhat.com> <20090105215850.GA22009@amt.cnet> <49631593.6030204@redhat.com> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Sheng Yang , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:41966 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbZAFJe5 (ORCPT ); Tue, 6 Jan 2009 04:34:57 -0500 In-Reply-To: <49631593.6030204@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.