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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B467BC433EF for ; Thu, 7 Oct 2021 19:07:50 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 62EE660F23 for ; Thu, 7 Oct 2021 19:07:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 62EE660F23 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2A6D68432A; Thu, 7 Oct 2021 19:07:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W7VmLkHR2_N; Thu, 7 Oct 2021 19:07:49 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1CCF484269; Thu, 7 Oct 2021 19:07:49 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id F332AC0011; Thu, 7 Oct 2021 19:07:48 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B2FAC000D for ; Thu, 7 Oct 2021 19:07:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1C351607BD for ; Thu, 7 Oct 2021 19:07:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNGz8skdE6Gh for ; Thu, 7 Oct 2021 19:07:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by smtp3.osuosl.org (Postfix) with ESMTPS id 88B236071A for ; Thu, 7 Oct 2021 19:07:44 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="226625440" X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="226625440" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2021 12:07:43 -0700 X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="713470498" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2021 12:07:43 -0700 Date: Thu, 7 Oct 2021 12:11:27 -0700 From: Jacob Pan To: Barry Song <21cnbao@gmail.com> Subject: Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA Message-ID: <20211007121127.53956635@jacob-builder> In-Reply-To: References: <1632256181-36071-1-git-send-email-jacob.jun.pan@linux.intel.com> <20211001123623.GM964074@nvidia.com> <20211004094003.527222e5@jacob-builder> <20211004182142.GM964074@nvidia.com> Organization: OTC X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: "Tian, Kevin" , Tony Luck , Dave Jiang , Raj Ashok , "Kumar, Sanjay K" , LKML , Christoph Hellwig , iommu@lists.linux-foundation.org, Jason Gunthorpe , mike.campin@intel.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Hi Barry, On Thu, 7 Oct 2021 18:43:33 +1300, Barry Song <21cnbao@gmail.com> wrote: > > > Security-wise, KVA respects kernel mapping. So permissions are better > > > enforced than pass-through and identity mapping. > > > > Is this meaningful? Isn't the entire physical map still in the KVA and > > isn't it entirely RW ? > > Some areas are RX, for example, ARCH64 supports KERNEL_TEXT_RDONLY. > But the difference is really minor. That brought up a good point if we were to use DMA API to give out KVA as dma_addr for trusted devices. We cannot satisfy DMA direction requirements since we can't change kernel mapping. It will be similar to DMA direct where dir is ignored AFAICT. Or we are saying if the device is trusted, using pass-through is allowed. i.e. physical address. Thoughts? Thanks, Jacob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu