From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/3] KVM: Interrupt mask notifiers for ioapic Date: Mon, 05 Jan 2009 22:57:02 +0200 Message-ID: <4962741E.7050204@redhat.com> References: <1231085685-32201-1-git-send-email-avi@redhat.com> <1231085685-32201-3-git-send-email-avi@redhat.com> <20090105182930.GB5592@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sheng Yang , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:33986 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753129AbZAEU4s (ORCPT ); Mon, 5 Jan 2009 15:56:48 -0500 In-Reply-To: <20090105182930.GB5592@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: > On Sun, Jan 04, 2009 at 06:14:44PM +0200, Avi Kivity wrote: > >> Allow clients to request notifications when the guest masks or unmasks a >> particular irq line. This complements irq ack notifications, as the guest >> will not ack an irq line that is masked. >> >> Currently implemented for the ioapic only. >> + >> +struct kvm_irq_mask_notifier { >> + void (*func)(struct kvm_irq_mask_notifier *kimn, int masked); >> > > bool masked? > > Hey, I'm the bool fanatic! >> @@ -128,6 +129,9 @@ static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val) >> ioapic->redirtbl[index].bits |= (u32) val; >> ioapic->redirtbl[index].fields.remote_irr = 0; >> } >> + mask_after = ioapic->redirtbl[index].fields.mask; >> + if (mask_before != mask_after) >> + kvm_fire_mask_notifiers(ioapic->kvm, index, mask_after); >> > > This can generate "spurious acks", for example: > > - inject irq > - guest masks, mask notifier cleans internal state to "acked". > - guest writes EOI > > But I suppose thats fine, since PIT (for example) is getting spurious > acks even without mask notifiers and so has to handle them. > If the mask happened for a long time then the guest would expect not to receive those interrupts. If it happened due to scheduling then we need to reinject them. I suppose we could measure descheduled time and correct appropriately. There previously existed logic that limited the pending count to some value (10?) so there wouldn't be a stream of interrupts injected into the guest endlessly. I expect in most cases, masking of the timer interrupt would not happen for short periods. You'd use eflags.if or apic.tpr to mask for short periods. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.