Received: by 10.192.165.148 with SMTP id m20csp1814611imm; Thu, 3 May 2018 05:58:16 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr0P2Br+XAFT2+v5NzFkxttee83pgAqnpmNryGQd/HZ9J26SSS7okNzqLMGSQ0HdRi7n6jX X-Received: by 2002:a65:5247:: with SMTP id q7-v6mr18939647pgp.27.1525352296657; Thu, 03 May 2018 05:58:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525352296; cv=none; d=google.com; s=arc-20160816; b=uG4YliERLoq8sXYC/xf6dxkm2+sI24UKNrQDfpv2hhzaO859lFVK6oNA3jDZhMGirT vimYnKgKkzbukQew8IpUrmWmTM6IdQVyVuSDFlLTtqdVbzpIeN9Dlt7DlATvV1xo24lN z3BQTHwc3RzdKO7tIgM6RPrBouDgRejink4o+/I3imVbALuGnCJbPECwRtwnDhIML27E 4GpG73fntra5snq9w51FLmvdEdkoBYyDGZpkgJUFxeDEhafJBmh9CeAIcNtU4Y3JcyaZ VGu3v4fcqDWTwS5GFYtCXD+JkQbC2knvdxyDKMDI4lt+A0yaA2dUfd/4hHJmdGS/QaU4 cTMA== 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=l3P35OIGmM8rqriIxsUX0Ezw4sv87imXgb9kVy3+oBA=; b=qToWGwEgU6Wj8l/u1l6cO0uJ2bZh+57CkcayA2Y2QOKyhLDuMIULdzvWXX4mKKtZ3Z ZN6MEofqpH0wk9lCidmek+wGd1dAlqARwZHFb/mwoPC+MRyBVf8N+pIrlAbOxht91YL3 vNAqegMcx4wkmrzn7pBOUCio/RKp75YDV4vI4LMxVyABs6DO4HuAmfsojAEew1iUkp0x xZ9KyT26GQLZkretxn+dYYO22sF2FYfJHzNggrXHuJYFRA0+ng6Zk/ASmc9EwKtxOdNx 7pVgh1FzRIR52NENLwTYKZ+yXHx+d1PLQYbp9lJQoY7GWPgyB+eZAgqaxftkBJvjkaYv gmvg== 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 j28si14098797pfe.337.2018.05.03.05.58.02; Thu, 03 May 2018 05:58:16 -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 S1751240AbeECM5p (ORCPT + 99 others); Thu, 3 May 2018 08:57:45 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38218 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751132AbeECM5l (ORCPT ); Thu, 3 May 2018 08:57:41 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 789CD401DEB7; Thu, 3 May 2018 12:57:41 +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 518342017F00; Thu, 3 May 2018 12:57:35 +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> <1292c46c-34ad-ea21-1f05-164044a5f35a@redhat.com> <20180503095823.zpxskdts7etpwl6x@debian> From: Jason Wang Message-ID: Date: Thu, 3 May 2018 20:57:33 +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: <20180503095823.zpxskdts7etpwl6x@debian> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 03 May 2018 12:57:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 03 May 2018 12:57:41 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.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日 17:58, Tiwei Bie wrote: > On Thu, May 03, 2018 at 05:09:44PM +0800, Jason Wang wrote: >> 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. > You are right. Thanks! Are you suggesting to add a > reference to Michael's patch in this patch to make > sure that it won't be applied before that patch? Yes, better to have some notes, or maybe just squash that patch into this series. Let's wait for Michael's reply to see. Thanks > > Best regards, > Tiwei Bie > >> Thanks