From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 03/12] Remove KVM_REQ_PENDING_TIMER. Date: Wed, 02 Dec 2009 16:16:53 +0200 Message-ID: <4B1676D5.8070209@redhat.com> References: <1259678201-11203-1-git-send-email-clalance@redhat.com> <1259678201-11203-4-git-send-email-clalance@redhat.com> <4B1568AF.6010100@siemens.com> <4B1664BD.7040201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm@vger.kernel.org To: Chris Lalancette Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62404 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754121AbZLBOQu (ORCPT ); Wed, 2 Dec 2009 09:16:50 -0500 In-Reply-To: <4B1664BD.7040201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/02/2009 02:59 PM, Chris Lalancette wrote: > On 12/01/2009 08:04 PM, Jan Kiszka wrote: > >> Chris Lalancette wrote: >> >>> KVM_REQ_PENDING_TIMER is set and cleared in a couple of places, >>> but it never seems to be actually checked. Remove it. >>> >>> >> I would suggest to study the introducing commit >> 06e05645661211b9eaadaf6344c335d2e80f0ba2. My strong feeling is that this >> removal is wrong. >> > Ah, thanks. Now I see what you mean. In newer KVM, if you are in > __vcpu_run() and are in the while (r> 0) loop, after you've > done kvm_inject_pending_timer_irqs(), but before you do the next > __vcpu_run() (and hence disabled local IRQs), you could receive an > hrtimer callback. In that case I guess you would hit the > if (vcpu->requests || need_resched() || signal_pending()) test, don't > inject the interrupt, and possibly spend a long time in the guest > before an unrelated event causes the exit and hence causes the timer > injection. > > Well, that certainly is a bit subtle :). I think I might submit a > patch to at least put a comment in vcpu_enter_guest() about this. > > It is, and I don't like it much either. > Unfortunately, this does sort of put a damper on what's going on later > in the series. If the i8254 doesn't belong to the BSP (which it really > shouldn't), then I don't know which vcpu to raise the bit on. Maybe I > can do it in the kvm_irq_delivery_to_apic() function, or > kvm_apic_set_irq(). I'll take a look at that. > We shouldn't have that bit at all. An alternative is to make the pic/ioapic work in irq context (spin_lock_irq() and friends) and queue the interrupt directly from the hrtimer instead of the vcpu. My worry is that we have quite a bit of work to do in irq context if the interrupt is broadcast and if we have many vcpus; maybe we can use a work_struct in that case. -- error compiling committee.c: too many arguments to function