Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2088158ybv; Fri, 21 Feb 2020 08:40:11 -0800 (PST) X-Google-Smtp-Source: APXvYqxvKB2BbPwaJF2xqJ5o/7ZYA4ZnHaBwfFu+i+TtiKRodumpGEEuxqgA2njruZvKeLquYnCS X-Received: by 2002:aca:5582:: with SMTP id j124mr2654633oib.20.1582303211720; Fri, 21 Feb 2020 08:40:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582303211; cv=none; d=google.com; s=arc-20160816; b=FJBj9b4uwLrNCqDwAQkWPcLepPXjlH0pUDlDX4bZCcYFLzBboNf3zgtygZBq63iqGs OKjI6GKlc18tOwvUAuOJ7lfCWK9defNf7oiTfwrE7civGA89kjlFGlmAA0imRoQeky0h O5jMFS6XTFJNbXxG9d85k0WB7duBw7A89DQ45vC24DukWt0ZSPsVqMsS/lP3HZ8XRg+s qBkop3Q2FAgctq2KcVd5YQ4pT7IsoNQlcI6piA0FZEw3lAcnLqtFbjoNvrXyJLGEb68t mlcqppO+5y5drNveYBpU3A41s0V5C9Nk3iYegegj26eptArxbTOYAnMd7fc4cG0QuXXR c+IQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=JVvcvh1PWAw+uLrxQBMyC+xWsRGwPHUTGDKnLbPxiy8=; b=gLRZlh2xguG7vMKIeWNPh6QnxAhx5cr5ej0aO0QRtpkWljwmtueQ6/TnNFNZuZ4hc0 BVFiIkHy4wfhOb88XbK2vc3bN7c5Ep1IPrWJOKDVqLeG8067lgk0lN6zpVrmJ6JcNZEa zXuUSxdhFI7RI3S6mEAErwuX2kRkBCr6WTz/jtbH8ozad2wIZyqsBCF5Gsowi3qPs0gp FutByneXGFvMfxyHkRKrjYKWAQ9DJ31HG2kkIYqbNaTBRVn6zsdOlN07+GiNg3DKsRZT aCSbgFj7bGF6pS6ss96GC4gw4m3M5LKiHbUBTtYAk2T5YUTQYDKqRxPedRKjVWaofHRE wtEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p12si1618700otk.173.2020.02.21.08.39.58; Fri, 21 Feb 2020 08:40:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726877AbgBUQjm (ORCPT + 99 others); Fri, 21 Feb 2020 11:39:42 -0500 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 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 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 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> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.