From nobody Sun Apr 28 15:36:43 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511876951698365.5414076563371; Tue, 28 Nov 2017 05:49:11 -0800 (PST) Received: from localhost ([::1]:38069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJgFx-0000vJ-VL for importer@patchew.org; Tue, 28 Nov 2017 08:49:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJgDv-00080q-Ry for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:47:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJgDu-0003BV-Mf for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:46:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53588) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJgDu-0003BA-FK for qemu-devel@nongnu.org; Tue, 28 Nov 2017 08:46:54 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E33B281DFB for ; Tue, 28 Nov 2017 13:46:52 +0000 (UTC) Received: from redhat.com (unknown [10.35.206.54]) by smtp.corp.redhat.com (Postfix) with SMTP id 03E0960317; Tue, 28 Nov 2017 13:46:45 +0000 (UTC) Date: Tue, 28 Nov 2017 15:46:44 +0200 From: Victor Kaplansky To: qemu-devel@nongnu.org Message-ID: <20171128133123.17372-1-vkaplans@redhat.com> MIME-Version: 1.0 Content-Disposition: inline X-Mutt-Fcc: =sent X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 28 Nov 2017 13:46:52 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] vhost-user spec: Clarify policy on setting log_base X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Victor Kaplansky , Maxime Coquelin , "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Victor Kaplansky If we allow qemu to change logging area after it was already established, it may require from the backend to acquire a lock on each access to the log_base, which has a potential quite a big performance hit. Thus we would like to clarify in the spec, that qemu is not expected to resize or remap the logging area, and backend implementations can safely ignore subsequent requests to log_base modifications. Signed-off-by: Victor Kaplansky Suggested-by: Maxime Coquelin --- docs/interop/vhost-user.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt index 954771d0d8..7ab31e57ef 100644 --- a/docs/interop/vhost-user.txt +++ b/docs/interop/vhost-user.txt @@ -257,6 +257,12 @@ Where addr is the guest physical address. =20 Use atomic operations, as the log may be concurrently manipulated. =20 +Note that master is not expected to issue more than one VHOST_USER_SET_LOG= _BASE +request before the rings are fully stopped by the master. Thus no modifica= tions +to log_base address are allowed before the rings are restated and the clie= nt +can ignore all subsequent VHOST_USER_SET_LOG_BASE requests after the log_b= ase +address has been established. + Note that when logging modifications to the used ring (when VHOST_VRING_F_= LOG is set for this ring), log_guest_addr should be used to calculate the log offset: the write to first byte of the used ring is logged at this offset = from --=20 2.14.2