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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 3931DC46470 for ; Tue, 7 Aug 2018 06:16:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E161321A12 for ; Tue, 7 Aug 2018 06:16:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="RkQQ033D" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E161321A12 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388118AbeHGI3Z (ORCPT ); Tue, 7 Aug 2018 04:29:25 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:38176 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727725AbeHGI3Z (ORCPT ); Tue, 7 Aug 2018 04:29:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T8Wd1t5PU46+WfaSZwPqERmkEjDJ0QSeK+wQkFhfp0M=; b=RkQQ033DQ/hYOUhe2CEIVS8NI 5c9e1qRjn35ecGQvTz+GPzquWq8isS+ieVR0tqF8ys9c3kjvVuP95fTDxsI+nioc/f4JKJcwnOtG/ Dhs+HjmpAj/9FonF1dzYB8gKxncNLvGWgNSHEaBDciAtBPrkTfEfpNtBdKoyhm8LtIpqEtQ9UTNym Cm90JUNq7QQq+ib4BD1BiU+Qg5f51lLO6qhAZo2LyiVbQDb9s1zFsE3gmdPPmSsFg4P4Jl/Tbip4H 7iZHlMZIpvZcntFDsgE/DZ2ddByRePL2t8P1rMXQ8wwfq84K5cB8Qp6xZNVSKpacC6KCE0j+AKyGA VhWCy/4+g==; Received: from hch by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fmvIL-0003OD-O2; Tue, 07 Aug 2018 06:16:37 +0000 Date: Mon, 6 Aug 2018 23:16:37 -0700 From: Christoph Hellwig To: Benjamin Herrenschmidt Cc: "Michael S. Tsirkin" , Christoph Hellwig , Will Deacon , Anshuman Khandual , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, aik@ozlabs.ru, robh@kernel.org, joe@perches.com, elfring@users.sourceforge.net, david@gibson.dropbear.id.au, jasowang@redhat.com, mpe@ellerman.id.au, linuxram@us.ibm.com, haren@linux.vnet.ibm.com, paulus@samba.org, srikar@linux.vnet.ibm.com, robin.murphy@arm.com, jean-philippe.brucker@arm.com, marc.zyngier@arm.com Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices Message-ID: <20180807061637.GB32709@infradead.org> References: <20180803070507.GA1344@infradead.org> <20180803220443-mutt-send-email-mst@kernel.org> <051fd78e15595b414839fa8f9d445b9f4d7576c6.camel@kernel.crashing.org> <20180805031046-mutt-send-email-mst@kernel.org> <20180806164106-mutt-send-email-mst@kernel.org> <20180806233024-mutt-send-email-mst@kernel.org> <0967fc30001323e6e38ed12c8dba8ee3d1aa13f5.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0967fc30001323e6e38ed12c8dba8ee3d1aa13f5.camel@kernel.crashing.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 07, 2018 at 07:26:35AM +1000, Benjamin Herrenschmidt wrote: > > I think Christoph merely objects to the specific implementation. If > > instead you do something like tweak dev->bus_dma_mask for the virtio > > device I think he won't object. > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? It will be new in 4.19: http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/f07d141fe9430cdf9f8a65a87c41 > So, something like that would be a possibility, but the problem is that > the current virtio (guest side) implementation doesn't honor this when > not using dma ops and will not use dma ops if not using iommu, so back > to square one. > > Christoph seems to be wanting to use a flag in the interface to make > the guest use dma_ops which is what I don't understand. As-is virtio devices are very clearly and explcitly defined to use physical addresses in the spec. dma ops will often do platform based translations (iommu, offsets), so we can't just use the plaform default dma ops and will need to opt into them. > What would be needed then would be something along the lines of virtio > noticing that dma_mask isn't big enough to cover all of memory (which > isn't something generic code can easily do here for various reasons I > can elaborate if you want, but that specific test more/less has to be > arch specific), and in that case, force itself to use DMA ops routed to > swiotlb. > > I'd rather have arch code do the bulk of that work, don't you think ? There is nothing architecture specific about that. I've been working hard to remove all the bullshit architectures have done in their DMA ops and consolidating them into common code based on rules. The last thing I want is another vector for weird underspecified arch interfaction with DMA ops, which is exactly what your patch below does.