Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1391356imm; Wed, 23 May 2018 15:30:14 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpQ78sMBWO0g+vNIMg1bYIMLq0dLjY8s4P4+YedfWXPoe+EL2mXPSawxG+DPvtzlpIi0FhI X-Received: by 2002:a62:49d7:: with SMTP id r84-v6mr4597915pfi.146.1527114614071; Wed, 23 May 2018 15:30:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527114614; cv=none; d=google.com; s=arc-20160816; b=IewvTUFMTAQ2vxTB72HZnbrwblZ9vwi1Hxb3LqB9Imq6adCj8/nTaeDw8XVLSJB5oC vq7h+ecfVAvlivq6AT9c3c6O+kUd9HZmGNfU7qJbe03fVcHTDnP12N2BNkin/bX1aK17 guIlGudRro+IW+EeZdOutJTK+vr4vtZCjyUIp05d8brVV8Noyd8mP6m3baLNzUHfHU60 yxSID5de47I5ssgg7iFzr41++XZiqOwmvMKUEiEY4wX4vfD5yydNhHyJXKD1S4V2HqEu mhRFLaJxQoPWRkBfqtPREHIGReda9PG81a67RfIL3rztr0QO6um3TErT613yM+qgbX1j N+8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=3dg2evnWuOnQ8G3Yg38YXTRc7kiPKZcwosC5mXCt49Q=; b=ECvcCatLIT5/t17MRP5Hca7hz6jOnEayb9H2KZvQoQWJcjTfa2rhgP8kdsbX5YvjMc 6IuLiQlYYInqV30fGV30KWEevwvG9DHSBMYlh2GEOce3RtS7rCtPQy85GiMT6++x0g0t 1AOfgwkcOnR/V8nUKAi78QOMT7nc0WMTH3gZ0NGnVush2XoyvMlHijtainSwYhkrEfSG 6vmk18+8keXUdrLrUqBl7z4s19Ce+LIK5ATT/8i5okKDm5b0o6FBPiBKgbrDcdu/FkRZ hljZVvnuHncEYCjJREflFBFvSsfENF2GuZq/9MmGw1X8+mh7uFkGOCoGZAI7v6ZeDl1Y r5KA== 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 s23-v6si20080572plr.458.2018.05.23.15.29.58; Wed, 23 May 2018 15:30:14 -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; 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 S934892AbeEWW2X (ORCPT + 99 others); Wed, 23 May 2018 18:28:23 -0400 Received: from gate.crashing.org ([63.228.1.57]:51422 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933083AbeEWW2U (ORCPT ); Wed, 23 May 2018 18:28:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w4NMR5I1016251; Wed, 23 May 2018 17:27:06 -0500 Message-ID: Subject: Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices From: Benjamin Herrenschmidt To: "Michael S. Tsirkin" , Anshuman Khandual Cc: 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, hch@infradead.org Date: Thu, 24 May 2018 08:27:04 +1000 In-Reply-To: <20180523213703-mutt-send-email-mst@kernel.org> References: <20180522063317.20956-1-khandual@linux.vnet.ibm.com> <20180523213703-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 (3.28.1-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side sufficient? I thought I had replied to this... There are a couple of reasons: - First qemu doesn't know that the guest will switch to "secure mode" in advance. There is no difference between a normal and a secure partition until the partition does the magic UV call to "enter secure mode" and qemu doesn't see any of it. So who can set the flag here ? - Second, when using VIRTIO_F_IOMMU_PLATFORM, we also make qemu (or vhost) go through the emulated MMIO for every access to the guest, which adds additional overhead. Cheers, Ben. > > > > arch/powerpc/include/asm/dma-mapping.h | 6 ++++++ > > arch/powerpc/platforms/pseries/iommu.c | 11 +++++++++++ > > drivers/virtio/virtio_ring.c | 10 ++++++++++ > > 3 files changed, 27 insertions(+) > > > > diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h > > index 8fa3945..056e578 100644 > > --- a/arch/powerpc/include/asm/dma-mapping.h > > +++ b/arch/powerpc/include/asm/dma-mapping.h > > @@ -115,4 +115,10 @@ extern u64 __dma_get_required_mask(struct device *dev); > > #define ARCH_HAS_DMA_MMAP_COHERENT > > > > #endif /* __KERNEL__ */ > > + > > +#define platform_forces_virtio_dma platform_forces_virtio_dma > > + > > +struct virtio_device; > > + > > +extern bool platform_forces_virtio_dma(struct virtio_device *vdev); > > #endif /* _ASM_DMA_MAPPING_H */ > > diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c > > index 06f0296..a2ec15a 100644 > > --- a/arch/powerpc/platforms/pseries/iommu.c > > +++ b/arch/powerpc/platforms/pseries/iommu.c > > @@ -38,6 +38,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -1396,3 +1397,13 @@ static int __init disable_multitce(char *str) > > __setup("multitce=", disable_multitce); > > > > machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init); > > + > > +bool platform_forces_virtio_dma(struct virtio_device *vdev) > > +{ > > + /* > > + * On protected guest platforms, force virtio core to use DMA > > + * MAP API for all virtio devices. But there can also be some > > + * exceptions for individual devices like virtio balloon. > > + */ > > + return (of_find_compatible_node(NULL, NULL, "ibm,ultravisor") != NULL); > > +} > > Isn't this kind of slow? vring_use_dma_api is on > data path and supposed to be very fast. > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 21d464a..47ea6c3 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -141,8 +141,18 @@ struct vring_virtqueue { > > * unconditionally on data path. > > */ > > > > +#ifndef platform_forces_virtio_dma > > +static inline bool platform_forces_virtio_dma(struct virtio_device *vdev) > > +{ > > + return false; > > +} > > +#endif > > + > > static bool vring_use_dma_api(struct virtio_device *vdev) > > { > > + if (platform_forces_virtio_dma(vdev)) > > + return true; > > + > > if (!virtio_has_iommu_quirk(vdev)) > > return true; > > > > -- > > 2.9.3