Received: by 10.192.165.148 with SMTP id m20csp1570689imm; Thu, 3 May 2018 01:30:01 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpSvK01GGza3x2hqnKIA5dc5/2rj4uC0HN/Hl1I5Z9LcxRIbHhQzOnAnR2VBCiaji+dGVVz X-Received: by 2002:a63:7b55:: with SMTP id k21-v6mr18883161pgn.364.1525336200968; Thu, 03 May 2018 01:30:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525336200; cv=none; d=google.com; s=arc-20160816; b=D62n+hNPiSxVXf0eF9ZuNTneIq8dZZruVzztTAQbtTJlq6hY0gGPMk21bO/Qh5qnfO ZMYmrEHRw0WFdjL+KplVYim/+a/fwghvVBLlZPtx3oYulpLnxok8oN3GIwSq+aJplTI9 8lvy6Xa5TpseYUdOOyaW1aK30ctsRA27IPvomePyUPGuYMDVymCSjqr9zROMqGeiuO1F On7EkerpEFBoYeYVvc383NwcKBzg2gykIIwoQYZ9xIChuFfw3o0HqpImiNfMTV8RlxZf gfu8U2bGLG66IWkSLZpCHSi0dfzLGWjSkhhllc46vAMPqMQ0zfbHt8LDVn4xBPA3oRqU ugJw== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=3EYaoqmcgoGQv/I2cKe/X+gVpKYGyTaBdPVWK0LIeqA=; b=oauVyEwmAe8nluJ/+16jMHhYZy9Pd7AFl6Chg5hkA9W+US+oxwYOiNn09MXcP2hU1r IWjGe1rXcUOekp/iBM4l/LCX7qMRtMMb088aXqpPRuQQ0v0JxTx9k0UhgjZvglqVcfiC HYRbmqP3str8vE64BJANi+xxvdH7DESeolqH/Yua8hR+95xtyDAmJEmjWJwSKrCKTnsg HaCRLl6J89S9HDBZaQCC3f+dQZXBX7EpKEhP61r1v88npXp9dApR5P4RIyejT8WrAwf2 ReKBb0+vdZngXOnheM8A3XLECDnxy3/NdjqT++yLGHJrWftpmFmGXglLnaBUYvpH/PC2 /8Cw== 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 r2-v6si13452226pli.370.2018.05.03.01.29.46; Thu, 03 May 2018 01:30:00 -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 S1751140AbeECI3f (ORCPT + 99 others); Thu, 3 May 2018 04:29:35 -0400 Received: from mga01.intel.com ([192.55.52.88]:51862 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbeECI3c (ORCPT ); Thu, 3 May 2018 04:29:32 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 01:29:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,357,1520924400"; d="scan'208";a="51161583" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.164]) by fmsmga004.fm.intel.com with ESMTP; 03 May 2018 01:29:30 -0700 Date: Thu, 3 May 2018 16:30:15 +0800 From: Tiwei Bie To: Jason Wang 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 Subject: Re: [RFC] virtio: support VIRTIO_F_IO_BARRIER Message-ID: <20180503083015.kb7po26ga46g66tc@debian> References: <20180503025955.28816-1-tiwei.bie@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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