Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932848AbdGXRYY (ORCPT ); Mon, 24 Jul 2017 13:24:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53566 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932781AbdGXRYI (ORCPT ); Mon, 24 Jul 2017 13:24:08 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3212CFB90 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=alex.williamson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3212CFB90 Date: Mon, 24 Jul 2017 11:24:06 -0600 From: Alex Williamson To: Anup Patel Cc: Will Deacon , Robin Murphy , Joerg Roedel , Baptiste Reynal , Scott Branden , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, kvm@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com Subject: Re: [PATCH v2 1/2] vfio: Allow No-IOMMU mode without checking iommu_present() Message-ID: <20170724112406.42b69c8b@w520.home> In-Reply-To: <1500525154-5200-2-git-send-email-anup.patel@broadcom.com> References: <1500525154-5200-1-git-send-email-anup.patel@broadcom.com> <1500525154-5200-2-git-send-email-anup.patel@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 24 Jul 2017 17:24:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1737 Lines: 45 On Thu, 20 Jul 2017 10:02:33 +0530 Anup Patel wrote: > Not allowing No-IOMMU mode for devices already having > iommu_ops on their bus is very conservative. > > We now have IOMMU (such as ARM SMMU) which can bypass > transcations when IOMMU is not configured for a given > device. In addition, it is not necessary to have all > devices on bus to be upstream to an IOMMU on that bus. > > Due above reasons, having iommu_present() check for > VFIO No-IOMMU mode is not appropriate. > > Signed-off-by: Anup Patel > --- > drivers/vfio/vfio.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c > index 330d505..9d90de7 100644 > --- a/drivers/vfio/vfio.c > +++ b/drivers/vfio/vfio.c > @@ -124,11 +124,10 @@ struct iommu_group *vfio_iommu_group_get(struct device *dev) > #ifdef CONFIG_VFIO_NOIOMMU > /* > * With noiommu enabled, an IOMMU group will be created for a device > - * that doesn't already have one and doesn't have an iommu_ops on their > - * bus. We set iommudata simply to be able to identify these groups > - * as special use and for reclamation later. > + * that doesn't already have one. We set iommudata simply to be able > + * to identify these groups as special use and for reclamation later. > */ > - if (group || !noiommu || iommu_present(dev->bus)) > + if (group || !noiommu) > return group; > > group = iommu_group_alloc(); Nak, no-iommu is intentionally conservative. How do we tell the difference between the iommu_ops available to us with a fake group vs a proper group created by the iommu if we ignore iommu_present()? If an iommu exists, use it. Thanks, Alex