From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH] KVM: optimize apic interrupt delivery Date: Tue, 11 Sep 2012 15:09:51 +0300 Message-ID: <20120911120951.GK20907@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> <504F0748.5010705@redhat.com> <20120911094546.GA23020@redhat.com> <504F28D4.4050105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, mtosatti@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32952 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852Ab2IKMJy (ORCPT ); Tue, 11 Sep 2012 08:09:54 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8BC9rWc018648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Sep 2012 08:09:53 -0400 Content-Disposition: inline In-Reply-To: <504F28D4.4050105@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Sep 11, 2012 at 03:04:36PM +0300, Avi Kivity wrote: > On 09/11/2012 12:45 PM, Gleb Natapov wrote: > >> >> > >> > 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. > > Then it is just simpler to sigkill the guest right away. What's the > > point in returning error if you believe that userspace can't handle it > > and will likely not run long enough to even get to userspace due to > > memory shortage. > > Syscalls don't SIGKILL (well except kill(2)). They report errors. The > only other alternative is SIGBUS. > Anything that will put guest out of its misery. > > > >> > >> > > >> >> >> > >> >> > 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. > >> > > The patch does it. Windows sends a lot of all but self IPIs too. > > I thought it bailed out if a destination shorthand was used? > This is highly sophisticated patch! It checks for APIC_DEST_SELF before bailing out. if (irq->shorthand == APIC_DEST_SELF) { *r = kvm_apic_set_irq(src->vcpu, irq); return true; } if (irq->shorthand) return false; -- Gleb.