From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH] KVM: optimize apic interrupt delivery Date: Tue, 11 Sep 2012 12:29:06 +0300 Message-ID: <504F0462.5050103@redhat.com> References: <20120910130915.GB20907@redhat.com> <20120910144438.GA19741@redhat.com> <20120910161754.GB25827@redhat.com> <20120910170522.GC25827@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, mtosatti@redhat.com To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49428 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756792Ab2IKJ3J (ORCPT ); Tue, 11 Sep 2012 05:29:09 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8B9T87r030901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Sep 2012 05:29:08 -0400 In-Reply-To: <20120910170522.GC25827@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/10/2012 08:05 PM, Gleb Natapov wrote: > On Mon, Sep 10, 2012 at 07:17:54PM +0300, Gleb Natapov wrote: >> > > + return 0; >> > > +} >> > > + >> > > +static inline int kvm_apic_set_id(struct kvm_lapic *apic, u8 id) >> > > +{ >> > > + apic_set_reg(apic, APIC_ID, id << 24); >> > > + return recalculate_apic_map(apic->vcpu->kvm); >> > > +} >> > > + >> > > +static inline int kvm_apic_set_ldr(struct kvm_lapic *apic, u32 id) >> > > +{ >> > > + apic_set_reg(apic, APIC_LDR, id); >> > > + return recalculate_apic_map(apic->vcpu->kvm); >> > > +} >> > > + >> > >> > return value of these functions seems never checked. >> > >> Yes, the problem is that we can do nothing about the failure if failure >> happens during guest write. We can. Return -ENOMEM all the way up to userspace. >> > Actually I have an idea how to handle the error. Never return one. If > map cannot be allocated go slow path always. phys_map should be checked > for NULL during delivery in this case obviously. That's better of course (though we have to beware of such tricks, but in this case the slow path is regularly exercised so it should keep working). -- error compiling committee.c: too many arguments to function