Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3828227imm; Mon, 30 Jul 2018 04:20:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf2DhzRM+fEM39qmobg6yLZiLYcIR/lvbDchovGG1F4TOUly9D15Mu3HKhHQ8rAf8tOSxtA X-Received: by 2002:a63:ce43:: with SMTP id r3-v6mr15873825pgi.439.1532949642231; Mon, 30 Jul 2018 04:20:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532949642; cv=none; d=google.com; s=arc-20160816; b=uR/ldSfWIF2McCYDbMrxIcFQV2wI9rfurrmCLK2FWpKpCOPuqOarmD+lN68fGq7xhR bx7pJjXVm8MP2opqlvItc+F2JyagPwRKwSKhyYjcWcNeTC8gxlmhCpsqDdOuwZ9oC2h2 0jB1rLwhHacIikQgRNq4b+C1R2neSBBOqBB5g0NzTrUcRgEdnIWIyqzGkbraHPS2oImB Nfg1L9v8Vg7nKX2sBeB5knFTZdsGcqvc0N557lLh5alvqFclozQuQbB3owEDYWIIsRCA /k7iSFHy3qdVDPmMsNYEe00b5KIOsg87PLzViwJj7IQd1m2txfiC0knaNfc/cvytehvO ZFyQ== 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:dkim-signature:arc-authentication-results; bh=on+OyK3pSACmjq3MttzOOZBnePfNP7HOM896lfbN8AU=; b=GwwBrlSlxD3B50hQisMBaalpsFtIcWZKteaqPN+HS+h+0Lm/9bwkkRxzewBy9IAuKH m3vhy5J262QX8OShu3iY97xpakWgaSjNvf9c/cGI4hcrPZLBg0OCK4WqjSIarDCqDK81 iV8F/Fh2IU/TsxrFCxTNtNwVUZrsWrR+95MtJoecM/GUFL9+iFNbI7t9UQAbMIqzKkqc kbvgR48GYWimI3LFGnSMzBuoVgq/QWoCXKRmlNBc1yTE15Nw+6cvtd8U3EmHmcA5XI1+ XARpUL32wSml23ouFbLWACa0LElAb3PrWx/t7+9qNiGDE2H/wOCWHpWqx+30jTn+GIfJ c1BQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=LWPRBwL+; 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 a14-v6si11135810pfl.349.2018.07.30.04.20.04; Mon, 30 Jul 2018 04:20:42 -0700 (PDT) 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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=LWPRBwL+; 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 S1727063AbeG3Mwh (ORCPT + 99 others); Mon, 30 Jul 2018 08:52:37 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:54452 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726584AbeG3Mwg (ORCPT ); Mon, 30 Jul 2018 08:52:36 -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=on+OyK3pSACmjq3MttzOOZBnePfNP7HOM896lfbN8AU=; b=LWPRBwL+V6GFmtug2JtUQo993 vB/Hwlmy/su9gok7SgCJWfGtC7xQigx29nUFAXCblpvEyif60JImCZMVskBFmL44H7Bkgn56UIelp hluGjMGR/y9S2EE8OP2Dn/XxQE0QLfnXKRsiZFQth6pyZipnxDvsYFkweSGEpJL9nQyunoS6Ja+0N hxBb60Y63jUfNnJcVLiFDoCHJq4FY4nltCVKKJrJ6SsGJSPxP7OHJjTETPVdg2SRTLEyu2zIjYciM /YYo7120rOjtNDLuMf9kXAPzfv+AhTb2J4tmQIr2QnD4FTv1W6KEbIGZ8C6VLRvfmyN70VMUFhKkd OxTWJ7USw==; Received: from hch by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fk6Be-0004kH-Es; Mon, 30 Jul 2018 11:18:02 +0000 Date: Mon, 30 Jul 2018 04:18:02 -0700 From: Christoph Hellwig To: "Michael S. Tsirkin" Cc: 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, benh@kernel.crashing.org, 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: <20180730111802.GA9830@infradead.org> References: <20180720035941.6844-1-khandual@linux.vnet.ibm.com> <20180727095804.GA25592@arm.com> <20180730093414.GD26245@infradead.org> <20180730125100-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180730125100-mutt-send-email-mst@kernel.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 Mon, Jul 30, 2018 at 01:28:03PM +0300, Michael S. Tsirkin wrote: > Let me reply to the "crappy" part first: > So virtio devices can run on another CPU or on a PCI bus. Configuration > can happen over mupltiple transports. There is a discovery protocol to > figure out where it is. It has some warts but any real system has warts. > > So IMHO virtio running on another CPU isn't "legacy virtual crappy > virtio". virtio devices that actually sit on a PCI bus aren't "sane" > simply because the DMA is more convoluted on some architectures. All of what you said would be true if virtio didn't claim to be a PCI device. Once it claims to be a PCI device and we also see real hardware written to the interface I stand to all what I said above. > With this out of my system: > I agree these approaches are hacky. I think it is generally better to > have virtio feature negotiation tell you whether device runs on a CPU or > not rather than rely on platform specific ways for this. To this end > there was a recent proposal to rename VIRTIO_F_IO_BARRIER to > VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > e.g. what if it's a VF - is that real or not? But I can see something > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. I don't really care about the exact naming, and indeed a device that sets the flag doesn't have to be a 'real' device - it just has to act like one. I explained all the issues that this means (at least relating to DMA) in one of the previous threads. The important bit is that we can specify exact behavior for both devices that sets the "I'm real!" flag and that ones that don't exactly in the spec. And that very much excludes arch-specific (or Xen-specific) overrides.