Received: by 10.192.165.148 with SMTP id m20csp207023imm; Thu, 3 May 2018 18:16:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrz7BUz180Ffm/871ncxnFMIs2oI1iPaYhsdgfBayuu/PzfHzZiG/4kNy9v2W3VoRvep9hD X-Received: by 2002:a63:b95d:: with SMTP id v29-v6mr10139180pgo.417.1525396585802; Thu, 03 May 2018 18:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525396585; cv=none; d=google.com; s=arc-20160816; b=hXd9EPDwPQo0rXJQO8r9v1fio4HzJOnJn2naWQdO8EDtoP6zfhwk8Ykk9mlX2JanY8 6MeYvldbW2S3sC3k1MoI0hd5NTtRS/qurP/ASDxpVAFiRwp0iN0F+GQCw0YWlGAeCyPT 9PG9xA3nNLiHbk+N3xuf9snjNiwA+7r/gxq0jzmOp+mHsYcFWQwEu8aQ7YMkuBgWiFPR jDqWKPzMbSTSSgfnnV+t8lRxbQ52CPQ9h6PSN/De6fj4KR/uaZ/7Zt+kKsqgafZpE2h+ 2DStqg/gmPyCuy0W0HAdO42kV5ZyRhAkI6V7AP9THonyREvrd4KfXZ6VDFBn3uZpmWv7 z28A== 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:arc-authentication-results; bh=VO8DWNhlQCdvz1DROcy6VZ9SS8LBKFaHbslEwSfKXlQ=; b=uC99jw998qXeLasn94icGmh3vbRowuS/qQ/BMLGRqcVuhmxWYQ7tSRgb/ElfiQ6dfQ HxvMenpc3WffeKZxn9ETMtbHqJbNdj8DeriioBLvpSFuWSjYlAFNz9vY16nPxskN/PdJ Agl6WsU9qETe7vLAZ0RwwbkqTVHImwyQvuypgWJM/Rzy9UR3UZE9UBx3qaJSFuHF25o2 Mj76C1Eqf6uTkk5vvUPj07NkqUy8023PhPwCJ7z5NUgDEL7u/1QDK88nDsmTU/KgeoIF 9N8r2kup7DIwWo3JjUosIZnZgkbnup43i+BRyeGNyrf1jHGCubnO3wAB/vqLLglyQsXH XJoQ== 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 k33-v6si14938092pld.100.2018.05.03.18.16.11; Thu, 03 May 2018 18:16:25 -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 S1751393AbeEDBOJ (ORCPT + 99 others); Thu, 3 May 2018 21:14:09 -0400 Received: from mga07.intel.com ([134.134.136.100]:24194 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbeEDBOI (ORCPT ); Thu, 3 May 2018 21:14:08 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 18:14:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,360,1520924400"; d="scan'208";a="39140612" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.164]) by orsmga006.jf.intel.com with ESMTP; 03 May 2018 18:14:06 -0700 Date: Fri, 4 May 2018 09:14:51 +0800 From: Tiwei Bie To: "Michael S. Tsirkin" Cc: jasowang@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 Subject: Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER Message-ID: <20180504011451.qf4po3s76adxxulf@debian> References: <20180503025955.28816-1-tiwei.bie@intel.com> <20180503203108-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180503203108-mutt-send-email-mst@kernel.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 03, 2018 at 08:57:20PM +0300, Michael S. Tsirkin wrote: > On Thu, May 03, 2018 at 10:59:55AM +0800, 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 > > Thanks! > > > --- > > 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; > > One issue worth looking at is that at least on Intel strong barriers are > actually typically overkill. We should probably switch weak_barriers == > false case over to dma barriers. Jason suggested me to add a reference or some notes in this patch about your patch: "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" > > > @@ -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 > > Any virtio UAPI changes must be CC'd to one of the virtio TC mailing lists > (subscriber-only, sorry about that). Got it! I'll send a new version and Cc virtio-dev. > > > @@ -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 */ > > Why 37? I'd use 34 I think. In the latest virtio spec draft, 34 and 35 have been taken by VIRTIO_F_RING_PACKED and VIRTIO_F_IN_ORDER. And 36 had been taken by VIRTIO_F_NOTIFICATION_DATA previously when I sent below proposal: https://lists.oasis-open.org/archives/virtio-dev/201804/msg00310.html But I just noticed that NOTIFICATION_DATA has been reverted from the repo, which means 36 is the next available bit. So I'll use it. Thanks for the reminder! Best regards, Tiwei Bie > > > -- > > 2.11.0