Received: by 10.192.165.148 with SMTP id m20csp1847925imm; Thu, 3 May 2018 06:26:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpkQ0j799jAJ2Q09tPMPp4ibuhvkCeNo1FSDuGoneAQ+eUBtjC+63sgBcxQM/clAf2tQw9C X-Received: by 2002:a17:902:5952:: with SMTP id e18-v6mr24146494plj.351.1525354019265; Thu, 03 May 2018 06:26:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525354019; cv=none; d=google.com; s=arc-20160816; b=Z4Eh90E0BCe+g0BjW45t2mm4ALFJBKs8VWcXP6hlgko3r7+Yxt66G5eutXdyz+VMBY nJqsmMMHrDewgq3Na1bpkmasZp4FGPrki5v0GF48v/CzdJcrVmi8V65DdZWxg8anTzra fQE+AzwkhkoRAwDkM7JiQKMKBWrDM/mWKwavA7uwWUk5bkIGqCDMv0jimhrryKvVmi+C 4/Fb1Pu1kkooqO831Rg6XDbBE1wYzIQY/fv/xkI7mlcVycA7jsoRIT7ZN3JBShYLV4F9 aiIST93OvZFYixQgU0wcSEBlwAqrFs8QaPs5PTApvSeJXqnH7ChR8XXFDK+EF7Ua7GsL kLBw== 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=ZnFnZS9DxU3Er/8kMeufk85bp82Ejqd1PzSPVxfvmtE=; b=eoy6hXl3YFuNiN4QoaiFwtono6C+cwb9T1zdOGjEmw+1wOj0cNjazEvC9obVB5nlN3 bI3hBm/S/deg/Bm70PZWLSdphu4CR0MYSSeHg66kVkNVdCgEkL6yNWKjhtsVqN9XeSaf V2EMZwE1pQDn+22W9ALRFa+oWFf4LT2ftj+jpt04PRbd67p53++wmCmF47CTGtVH2KpO MkhW/cOfPNgUCtsjni57yQ2sWOH8V+TX8AyfITZ4VnVgFYm20HFt2KQQ7wLP58vs7Apo h+gs1SyCCfA4Pdrf+LGncBR8lEcktG8Sz8wza5TyRzC4wG8pNFh7QNSGUXePhWpIFdd5 QF1Q== 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 24si628457pfj.6.2018.05.03.06.26.14; Thu, 03 May 2018 06:26:59 -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 S1751152AbeECN0F (ORCPT + 99 others); Thu, 3 May 2018 09:26:05 -0400 Received: from mga09.intel.com ([134.134.136.24]:8279 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbeECN0E (ORCPT ); Thu, 3 May 2018 09:26:04 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 06:26:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,358,1520924400"; d="scan'208";a="225507966" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.164]) by fmsmga006.fm.intel.com with ESMTP; 03 May 2018 06:26:02 -0700 Date: Thu, 3 May 2018 21:26:47 +0800 From: Tiwei Bie To: Stefan Hajnoczi Cc: mst@redhat.com, jasowang@redhat.com, pbonzini@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: <20180503132647.yfulyzbygdfgu2or@debian> References: <20180503025955.28816-1-tiwei.bie@intel.com> <20180503090652.GB5301@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180503090652.GB5301@stefanha-x1.localdomain> 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 10:06:52AM +0100, Stefan Hajnoczi 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 > > I should have thought of this earlier, but why is a new feature bit > necessary? If a hardware virtio device is in use, then the device > should already negotiate VIRTIO_F_IOMMU_PLATFORM (i.e. use DMA APIs and > IOMMU callbacks). > > Does disabling weak_barriers when VIRTIO_F_IOMMU_PLATFORM is set solve > the problem? The VIRTIO_F_IOMMU_PLATFORM feature can be set when the device is implemented in software. And I think we don't want the performance drop in this case. Best regards, Tiwei Bie