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:41:28 +0300 Message-ID: <504F0748.5010705@redhat.com> References: <20120910130915.GB20907@redhat.com> <20120910144438.GA19741@redhat.com> <20120910161754.GB25827@redhat.com> <20120910170522.GC25827@redhat.com> <504F0462.5050103@redhat.com> <20120911093502.GF20907@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]:49469 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758220Ab2IKJlc (ORCPT ); Tue, 11 Sep 2012 05:41:32 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8B9fVkT022271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Sep 2012 05:41:32 -0400 In-Reply-To: <20120911093502.GF20907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/11/2012 12:35 PM, Gleb Natapov wrote: > On Tue, Sep 11, 2012 at 12:29:06PM +0300, Avi Kivity wrote: >> 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. >> > There is no userspace to return error to if error happens on guest MMIO > write. Unless you mean return it as a return value of ioctl(VM_RUN) in > which case it is equivalent of killing the guest. That is what I meant. > And this is not fair > to a guest who did nothing wrong to suffer from our stupid optimizations :) > Actually I am not sure that returning to userspace in the middle of an > IO that is handled by a kernel is well defined in KVM ABI. If you get -ENOMEM when allocating a page without GFP_ATOMIC (or GFP_NOIO etc) then the entire host is dead anyway. The same thing can happen if the guest (or userspace) touches a yet-unallocated page, or if the page fault path fails to allocate mmu pages, or any of a thousand other allocations we have all over. > >> >> >> > 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). >> > Oh with Windows guests it has work to do for sure. This reminds me, we could speed up self-ipi for that. -- error compiling committee.c: too many arguments to function