Received: by 10.192.165.148 with SMTP id m20csp1603083imm; Thu, 3 May 2018 02:11:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrd6eJT5fdfhEOCHg5Ze4nuDO3FXc4zFP21uL+7RQE8p4HsUN9s/CpHIHaNSlR2PxWDAcCF X-Received: by 2002:a17:902:9886:: with SMTP id s6-v6mr22985967plp.380.1525338707871; Thu, 03 May 2018 02:11:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525338707; cv=none; d=google.com; s=arc-20160816; b=m7ckX5M0h1e5ll0W2hjsFNeJJU9vNrxbsnxwMrRwxefms3uqLoETL1rYt4R6s0LORm F6Bpb4RU5H/Lbt1L+j6jTYK8EIJmFhj2VTHDmaqbdXoZJDvZSCZSHmcj3ehO4GDHZl2x wwtIZ4zzVff2su9yutKPK07TEoS+fRtvUNwph7gP+3o5RI6KPW3SURnF08dVwDdEA2GL NGOgg+R8MlcRFv5U8FsFjrKSfHOu+l82z7E/rN3z7XL+8x7B/nAYOmikDa9hIh0HyfXF lUI3Q5tv2871AP7Xq3+wSMNNw3XBV6x1BKAPyLE/3yHANkryp0NH8nGh/ItJyw0fF9bV 5rpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=DuGtS4WRQjzCLjwl8wOQEmmBnwXkXIS74pc1eKlEMq8=; b=xFnuwetjLFhMF6DwbiGG2ZpQyY1Q74NsFt1RajqHVfIP2W0kKyz9rW8jC/AmjpL+fO YG7DP/q/ka5VuAGmkouZ7ZjQGUGhMQxUbYwWmG0hw3kA0JAXTrEx8JRsGxg+1NNhbRaX WN1fQcXv7MK85PLEa02XtY/2S4BZPZFGzjk53d1lQhMU9Gu5evlr8eEg+iIoGz8a6hmr 9cFNCJAffhB3ifKBgcDSGzNZnmlNdbCdCsyCVy4x9wwSTfG1sW7eWFYpSu4M4XYW5JmH +c6BUK7tWFdUcUX85oFCSOnr8SVJ0rklodkvN+l6QNVJtYfT/XIBHljTJwldX5FfmRqD k50w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r29-v6si11164700pgn.9.2018.05.03.02.11.33; Thu, 03 May 2018 02:11:47 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751505AbeECJJ6 (ORCPT + 99 others); Thu, 3 May 2018 05:09:58 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36372 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750969AbeECJJ4 (ORCPT ); Thu, 3 May 2018 05:09:56 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4CF2210D43F; Thu, 3 May 2018 09:09:56 +0000 (UTC) Received: from [10.72.12.18] (ovpn-12-18.pek2.redhat.com [10.72.12.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 28A7363533; Thu, 3 May 2018 09:09:47 +0000 (UTC) Subject: Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER To: Tiwei Bie Cc: mst@redhat.com, pbonzini@redhat.com, stefanha@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, dan.daly@intel.com, cunming.liang@intel.com, zhihong.wang@intel.com References: <20180503025955.28816-1-tiwei.bie@intel.com> <20180503083015.kb7po26ga46g66tc@debian> From: Jason Wang Message-ID: <1292c46c-34ad-ea21-1f05-164044a5f35a@redhat.com> Date: Thu, 3 May 2018 17:09:44 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180503083015.kb7po26ga46g66tc@debian> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 03 May 2018 09:09:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 03 May 2018 09:09:56 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jasowang@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018年05月03日 16:30, Tiwei Bie wrote: > On Thu, May 03, 2018 at 03:30:03PM +0800, Jason Wang wrote: >> On 2018年05月03日 10:59, Tiwei Bie wrote: >>> This patch introduces the support for VIRTIO_F_IO_BARRIER. >>> When this feature is negotiated, driver will use the barriers >>> suitable for hardware devices. >>> >>> Signed-off-by: Tiwei Bie >>> --- >>> drivers/virtio/virtio_ring.c | 5 +++++ >>> include/uapi/linux/virtio_config.h | 8 +++++++- >>> 2 files changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >>> index 21d464a29cf8..edb565643bf4 100644 >>> --- a/drivers/virtio/virtio_ring.c >>> +++ b/drivers/virtio/virtio_ring.c >>> @@ -996,6 +996,9 @@ struct virtqueue *__vring_new_virtqueue(unsigned int index, >>> !context; >>> vq->event = virtio_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX); >>> + if (virtio_has_feature(vdev, VIRTIO_F_IO_BARRIER)) >>> + vq->weak_barriers = false; >>> + >>> /* No callback? Tell other side not to bother us. */ >>> if (!callback) { >>> vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT; >>> @@ -1164,6 +1167,8 @@ void vring_transport_features(struct virtio_device *vdev) >>> break; >>> case VIRTIO_F_IOMMU_PLATFORM: >>> break; >>> + case VIRTIO_F_IO_BARRIER: >>> + break; >>> default: >>> /* We don't understand this bit. */ >>> __virtio_clear_bit(vdev, i); >>> diff --git a/include/uapi/linux/virtio_config.h b/include/uapi/linux/virtio_config.h >>> index 308e2096291f..6ca8d24bf468 100644 >>> --- a/include/uapi/linux/virtio_config.h >>> +++ b/include/uapi/linux/virtio_config.h >>> @@ -49,7 +49,7 @@ >>> * transport being used (eg. virtio_ring), the rest are per-device feature >>> * bits. */ >>> #define VIRTIO_TRANSPORT_F_START 28 >>> -#define VIRTIO_TRANSPORT_F_END 34 >>> +#define VIRTIO_TRANSPORT_F_END 38 >>> #ifndef VIRTIO_CONFIG_NO_LEGACY >>> /* Do we get callbacks when the ring is completely used, even if we've >>> @@ -71,4 +71,10 @@ >>> * this is for compatibility with legacy systems. >>> */ >>> #define VIRTIO_F_IOMMU_PLATFORM 33 >>> + >>> +/* >>> + * If clear - driver may use barriers suitable for CPU cores. >>> + * If set - driver must use barriers suitable for hardware devices. >>> + */ >>> +#define VIRTIO_F_IO_BARRIER 37 >>> #endif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ >> Hi: >> >> I believe this depends on Michael's patch of >> >> "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" >> >> ? >> >> Thanks > We already have below commit and some other related commits > in the tree: > > 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.") > > They should have already guaranteed that virtio_Xmb() will > be OK for hardware devices when vq->weak_barriers is false. > If my understanding is correct, the barriers used in this > case are overkill. So Michael's patch is to make the barriers > weaker (or better). > > Best regards, > Tiwei Bie Well, I think we need dma barriers for some platforms according to previous discussion? Without Michael's patch, we won't use any dma barriers in fact for virtio. Thanks