From patchwork Tue May 3 03:22:16 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 617743 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3qzRMP75B0z9t5C for ; Tue, 3 May 2016 13:23:13 +1000 (AEST) Received: from localhost ([::1]:39576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axQvU-0003OR-70 for incoming@patchwork.ozlabs.org; Mon, 02 May 2016 23:23:08 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axQv8-0002qK-Cw for qemu-devel@nongnu.org; Mon, 02 May 2016 23:22:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axQuw-0002Y8-J4 for qemu-devel@nongnu.org; Mon, 02 May 2016 23:22:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axQuw-0002Vd-BE for qemu-devel@nongnu.org; Mon, 02 May 2016 23:22:34 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CB1B81103; Tue, 3 May 2016 03:22:22 +0000 (UTC) Received: from pxdev.xzpeter.org (dhcp-14-147.nay.redhat.com [10.66.14.147]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u433MGp4026235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 May 2016 23:22:18 -0400 Date: Tue, 3 May 2016 11:22:16 +0800 From: Peter Xu To: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20160503032216.GA3296@pxdev.xzpeter.org> References: <1461827144-6937-1-git-send-email-peterx@redhat.com> <5721B980.4050903@web.de> <20160428091802.GH20143@pxdev.xzpeter.org> <20160429195214.GG15747@potion> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160429195214.GG15747@potion> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ehabkost@redhat.com, mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, alex.williamson@redhat.com, Jan Kiszka , wexu@redhat.com, pbonzini@redhat.com, marcel@redhat.com, imammedo@redhat.com, rth@twiddle.net Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote: > 2016-04-28 17:18+0800, Peter Xu: > > On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote: > >> Instead of fiddling with irq routes for the IOAPIC - where we don't need > >> it -, I would suggest to do the following: Send IOAPIC events via > >> kvm_irqchip_send_msi to the kernel. Only irqfd users (vhost, vfio) > >> should use the pattern you are now applying to the IOAPIC: establish > >> static routes as an irqfd is set up, and that route should be translated > >> by the iommu first, register an IEC notifier to update any affected > >> route when the iommu translation changes. > > > > Yes, maybe that's the right thing to do. Or say, when split irqchip, > > IOAPIC can avoid using GSI routes any more. If with that, I should > > also remove lots of things, like: IEC notifiers for IOAPIC, and all > > things related to msi route sync-up in IOAPIC codes with KVM (so I > > suppose we will save 24 gsi route entries for KVM, which sounds > > good). > > Sadly, we can't get rid of those GSI routes. KVM uses them to decide > whether it should forward EOI to userspace. And QEMU also has to remap > them, because KVM uses dest_id for that decision. Thanks to point out. Actually I have started to test the new patch and did encountered issue when using split irqchip mode. The above explains. :) So I think I will keep this part of codes un-touched in this series, and I can move forward with IR changes. However, I am still wondering whether we can avoid this in KVM when when using split irqchip mode? E.g., what if we do not do this check in KVM and let all EOI be passed to userspace? Like: --- --- I believe this will brings more user-space context switches, I just do not know how this will impact the system (only for curiosity :). Thanks, -- peterx diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 36591fa..c0a6e51 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -936,10 +936,6 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector) { int trigger_mode; - /* Eoi the ioapic only if the ioapic doesn't own the vector. */ - if (!kvm_ioapic_handles_vector(apic, vector)) - return; - /* Request a KVM exit to inform the userspace IOAPIC. */ if (irqchip_split(apic->vcpu->kvm)) { apic->vcpu->arch.pending_ioapic_eoi = vector; @@ -947,6 +943,10 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector) return; } + /* Eoi the ioapic only if the ioapic doesn't own the vector. */ + if (!kvm_ioapic_handles_vector(apic, vector)) + return; + if (apic_test_vector(vector, apic->regs + APIC_TMR)) trigger_mode = IOAPIC_LEVEL_TRIG; else