From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9C37C3F2D3 for ; Fri, 28 Feb 2020 14:57:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D764246AF for ; Fri, 28 Feb 2020 14:57:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="fx3F0RVJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D764246AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 05B896B0005; Fri, 28 Feb 2020 09:57:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00C7A6B0008; Fri, 28 Feb 2020 09:57:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64D86B000A; Fri, 28 Feb 2020 09:57:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id CD10A6B0005 for ; Fri, 28 Feb 2020 09:57:21 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 69DD5180AD801 for ; Fri, 28 Feb 2020 14:57:21 +0000 (UTC) X-FDA: 76539839082.12.twig34_7a5be4bd5ee46 X-HE-Tag: twig34_7a5be4bd5ee46 X-Filterd-Recvd-Size: 5063 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Feb 2020 14:57:20 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id j34so2205094qtk.4 for ; Fri, 28 Feb 2020 06:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=aXNQ0NABVZ/Zc8fXXYZpSz3dqh4Ns6QlhvK6/kwYM2k=; b=fx3F0RVJpvuGR0vU2fusOG/NqXxNQdLCppTq9XL99VJF79clWgcp5+agQ8Bkdn764W /6H4SP43zfEgHKiNsbn3EkZXEI5eftR/AZNv5GJYTZnxTXZRyq9aw7ICgIKMn8l0jnUx 9LorGB67BgZ2aphSqsGjJO2u/nt3IEPqyy6blQp30BdEWnEUxTjjCoo7zwPmwtZJlkI3 e+qGqpZDRkSLznZ8x2vUdH6CsaxJ2HRW27+fCzEtPp5EqdbjknklIN9PHhf1PYIBAg+F PuUEX6g64YI1DZfAu0ym87ZYgi2PkqOOc/+5zxlIRaH10PX0tdO8PBQJ2rqvbzBeuTgk IVvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=aXNQ0NABVZ/Zc8fXXYZpSz3dqh4Ns6QlhvK6/kwYM2k=; b=jsTGQt5MMM+lYHttJAg54JTZW0O0A8FjaKsNisr7gd23tg5I4EHRo+uR8YJ+IzYFAr MoDq15xtsRbFeNeghL4RtZMwCcyPPqVri6uEscLAfk5wBL2JFxZFVtAdjwK6mondCi65 Wji6c9bzGid5JKUmha748cmDUftPkGnKUSJfj+XgiGoDMsVIXp+YmPhcM1LVFlhcPvph MmEKncumAJ9DwwaPiMSey+fSkioeWkdZlWkUpG3CY1zqPvo1KnNP+GqooCsh5Sg0jwAn 98JM7gRBchgxt0kVCwZ4UoUf8/HvMCHdibfFrHoMPuyEOfrI0Vs6fpsk8Lc8WrtLK7F/ kFtA== X-Gm-Message-State: APjAAAXOXXADpk22D3+hh1ZepCfr7eeJrMTOHerC5yUq9MSwVEjxcQw6 4DgIYlLrmuhniHXxiqEgPJw35Q== X-Google-Smtp-Source: APXvYqxZGwk4KQ+YAY4GsyBgYKpbiHklk+KncMw+8qgpUr+ys9QfMTdjm4TizVQ6yPrtfGJb79x/jw== X-Received: by 2002:ac8:2939:: with SMTP id y54mr4410279qty.109.1582901840269; Fri, 28 Feb 2020 06:57:20 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id f7sm5133445qtj.92.2020.02.28.06.57.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 28 Feb 2020 06:57:19 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1j7h4p-00034R-0q; Fri, 28 Feb 2020 10:57:19 -0400 Date: Fri, 28 Feb 2020 10:57:19 -0400 From: Jason Gunthorpe To: Jean-Philippe Brucker Cc: Jacob Pan , iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com, baolu.lu@linux.intel.com, Jonathan.Cameron@huawei.com, christian.koenig@amd.com, yi.l.liu@intel.com, zhangfei.gao@linaro.org, Jean-Philippe Brucker Subject: Re: [PATCH v4 02/26] iommu/sva: Manage process address spaces Message-ID: <20200228145718.GR31668@ziepe.ca> References: <20200224182401.353359-1-jean-philippe@linaro.org> <20200224182401.353359-3-jean-philippe@linaro.org> <20200226111320.3b6e6d3d@jacob-builder> <20200228144007.GB2156@myrica> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200228144007.GB2156@myrica> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 28, 2020 at 03:40:07PM +0100, Jean-Philippe Brucker wrote: > > > Device > > > + * 00:00.0 accesses address spaces X and Y, each corresponding to an > > > mm_struct. > > > + * Devices 00:01.* only access address space Y. In addition each > > > + * IOMMU_DOMAIN_DMA domain has a private address space, io_pgtable, > > > that is > > > + * managed with iommu_map()/iommu_unmap(), and isn't shared with the > > > CPU MMU. > > So this would allow IOVA and SVA co-exist in the same address space? > > Hmm, not in the same address space, but they can co-exist in a device. In > fact the endpoint I'm testing (hisi zip accelerator) already needs normal > DMA alongside SVA for queue management. This one is integrated on an > Arm-based platform so shouldn't be a concern for VT-d at the moment, but > I suspect we might see more of this kind of device with mixed DMA. Probably the most interesting usecases for PASID definately require this, so this is more than a "suspect we might see" We want to see the privileged kernel control the general behavior of the PCI function and delegate only some DMAs to PASIDs associated with the user mm_struct. The device is always trusted the label its DMA properly. These programming models are already being used for years now with the opencapi implementation. Jason