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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 2F2F0C35646 for ; Fri, 21 Feb 2020 16:39:47 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 08A8024650 for ; Fri, 21 Feb 2020 16:39:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08A8024650 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id CE94E22170; Fri, 21 Feb 2020 16:39:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep+WqD4u5K55; Fri, 21 Feb 2020 16:39:44 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id 98718203D2; Fri, 21 Feb 2020 16:39:44 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67DB4C07FE; Fri, 21 Feb 2020 16:39:44 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E87DC013E; Fri, 21 Feb 2020 16:39:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 37C9687FC9; Fri, 21 Feb 2020 16:39:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmfkmnBDFa4V; Fri, 21 Feb 2020 16:39:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by hemlock.osuosl.org (Postfix) with ESMTPS id AADBB87FC3; Fri, 21 Feb 2020 16:39:41 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 8C11368BFE; Fri, 21 Feb 2020 17:39:38 +0100 (CET) Date: Fri, 21 Feb 2020 17:39:38 +0100 From: Christoph Hellwig To: Halil Pasic Subject: Re: [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected Message-ID: <20200221163938.GC10054@lst.de> References: <20200220160606.53156-1-pasic@linux.ibm.com> <20200220160606.53156-3-pasic@linux.ibm.com> <20200220161309.GB12709@lst.de> <20200221153340.4cdcde81.pasic@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200221153340.4cdcde81.pasic@linux.ibm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: linux-s390@vger.kernel.org, Janosch Frank , "Michael S. Tsirkin" , Jason Wang , Cornelia Huck , Ram Pai , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , iommu@lists.linux-foundation.org, David Gibson , Michael Mueller , "Lendacky, Thomas" , Viktor Mihajlovski , Robin Murphy , Christoph Hellwig 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" On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote: > > Hell no. This is a detail of the platform DMA direct implementation. > > I beg to differ. If it was a detail of the DMA direct implementation, it > should have/would have been private to kernel/dma/direct.c. It can't given that platforms have to implement it. It is an arch hook for dma-direct. > Consider what would we have to do to make PCI devices do I/O trough > pages that were shared when the guest is running in a protected VM. The > s390_pci_dma_ops would also need to know whether to 'force dma uencrypted' > or not, and it's the exact same logic. I doubt simply using DMA direct > for zPCI would do, because we still have to do all the Z specific IOMMU > management. And your IOMMU can't deal with the encryption bit? In the case we could think of allowing IOMMU implementation to access it. But the point that it is an internal detail of the DMA implementation and by now means for drivers. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:56415 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725988AbgBUQjm (ORCPT ); Fri, 21 Feb 2020 11:39:42 -0500 Date: Fri, 21 Feb 2020 17:39:38 +0100 From: Christoph Hellwig Subject: Re: [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected Message-ID: <20200221163938.GC10054@lst.de> References: <20200220160606.53156-1-pasic@linux.ibm.com> <20200220160606.53156-3-pasic@linux.ibm.com> <20200220161309.GB12709@lst.de> <20200221153340.4cdcde81.pasic@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200221153340.4cdcde81.pasic@linux.ibm.com> Sender: linux-s390-owner@vger.kernel.org List-ID: To: Halil Pasic Cc: Christoph Hellwig , "Michael S. Tsirkin" , Jason Wang , Marek Szyprowski , Robin Murphy , linux-s390@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Christian Borntraeger , Janosch Frank , Viktor Mihajlovski , Cornelia Huck , Ram Pai , Thiago Jung Bauermann , David Gibson , "Lendacky, Thomas" , Michael Mueller On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote: > > Hell no. This is a detail of the platform DMA direct implementation. > > I beg to differ. If it was a detail of the DMA direct implementation, it > should have/would have been private to kernel/dma/direct.c. It can't given that platforms have to implement it. It is an arch hook for dma-direct. > Consider what would we have to do to make PCI devices do I/O trough > pages that were shared when the guest is running in a protected VM. The > s390_pci_dma_ops would also need to know whether to 'force dma uencrypted' > or not, and it's the exact same logic. I doubt simply using DMA direct > for zPCI would do, because we still have to do all the Z specific IOMMU > management. And your IOMMU can't deal with the encryption bit? In the case we could think of allowing IOMMU implementation to access it. But the point that it is an internal detail of the DMA implementation and by now means for drivers.