Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932301AbdGSL2o (ORCPT ); Wed, 19 Jul 2017 07:28:44 -0400 Received: from mail-ua0-f169.google.com ([209.85.217.169]:33600 "EHLO mail-ua0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754155AbdGSL2l (ORCPT ); Wed, 19 Jul 2017 07:28:41 -0400 MIME-Version: 1.0 In-Reply-To: References: <1500456838-18405-1-git-send-email-anup.patel@broadcom.com> <0dc860ed-a40c-1bfd-f584-225807edb25b@arm.com> From: Anup Patel Date: Wed, 19 Jul 2017 16:58:40 +0530 Message-ID: Subject: Re: [PATCH 0/5] FlexRM support in VFIO platform To: Robin Murphy Cc: Will Deacon , Joerg Roedel , Baptiste Reynal , Alex Williamson , Scott Branden , Linux Kernel , Linux ARM Kernel , Linux IOMMU , kvm@vger.kernel.org, BCM Kernel Feedback Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1507 Lines: 33 On Wed, Jul 19, 2017 at 4:55 PM, Robin Murphy wrote: > On 19/07/17 12:17, Anup Patel wrote: >> On Wed, Jul 19, 2017 at 4:27 PM, Robin Murphy wrote: >>> On 19/07/17 10:33, Anup Patel wrote: >>>> This patchset primarily adds Broadcom FlexRM reset module for >>>> VFIO platform driver. We also have minor improvments in IOMMU >>>> and VFIO driver to allow VFIO no-IOMMU mode access to FlexRM. >>> >>> I'm struggling to understand the IOMMU changes here - what's the >>> FlexRM's hardware relationship with the IOMMU, and how is it different >>> from any other device? Furthermore, if there *is* a relevant IOMMU >>> present, why would no-IOMMU mode need to be involved at all? >> >> We want to have FlexRM device accessible from user-space >> using VFIO platform with and without IOMMU. >> >> Currently, if IOMMU ops are available for platform bus then >> I cannot access FlexRM device using VFIO no-IOMMU mode. > > So does the FlexRM hardware master through the SMMU or not? If it does, > why do you need no-IOMMU mode? If it doesn't, then that's yet another > reason to fix the real problem, which is the utterly broken notion of > there being 'an IOMMU' on the platform 'bus', rather than papering over > it in VFIO. > We are not trying to paper-over the issue. The ARM SMMU will have limited number of SMRs so on a big SOC with large number of DMA-capable devices we can run-out of SMRs if we try to configure SMMU for all DMA-capable devices. Regards, Anup