Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753394AbbGIM2K (ORCPT ); Thu, 9 Jul 2015 08:28:10 -0400 Received: from 8bytes.org ([81.169.241.247]:41931 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752732AbbGIM2H (ORCPT ); Thu, 9 Jul 2015 08:28:07 -0400 Date: Thu, 9 Jul 2015 14:28:05 +0200 From: Joerg Roedel To: Alex Williamson Cc: Eric Auger , eric.auger@st.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, christoffer.dall@linaro.org, marc.zyngier@arm.com, pbonzini@redhat.com, avi.kivity@gmail.com, mtosatti@redhat.com, feng.wu@intel.com, b.reynal@virtualopensystems.com, linux-kernel@vger.kernel.org, patches@linaro.org Subject: Re: [RFC v2 0/6] IRQ bypass manager and irqfd consumer Message-ID: <20150709122805.GW18569@8bytes.org> References: <1436184692-20927-1-git-send-email-eric.auger@linaro.org> <1436289468.1391.89.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1436289468.1391.89.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1195 Lines: 25 On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote: > Hosting the bypass manager in kernel/irq seemed appropriate, but really > it could be anywhere. Does anyone have a different preference or > specifically want it under their scope? We had originally thought of > this as an IOMMU service, but I think we've generalized it beyond that. > I expect we should also add the necessary hooks to turn it into a > loadable module to keep the tinification folks happy, I'll incorporate > the current working changes and post a version with that. Yeah, this is only an IOMMU service on x86, afaik. So drivers/iommu is probably the wrong place to host it. Will there be any other producers than VFIO or any other consumers than KVM? If not, it should live in one of these spaces. KVM is probably the best choice, as any hardware feature that uses this targets virtualization, so there will hardly ever be another consumer than KVM. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/