From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id C3BF11B48A; Wed, 10 Oct 2018 12:18:44 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2018 03:18:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,364,1534834800"; d="scan'208";a="98115897" Received: from btwcube1.sh.intel.com (HELO debian) ([10.67.104.158]) by orsmga001.jf.intel.com with ESMTP; 10 Oct 2018 03:18:41 -0700 Date: Wed, 10 Oct 2018 18:17:25 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: dev@dpdk.org, zhihong.wang@intel.com, jfreimann@redhat.com, nicknickolaev@gmail.com, i.maximets@samsung.com, bruce.richardson@intel.com, alejandro.lucero@netronome.com, dgilbert@redhat.com, stable@dpdk.org Message-ID: <20181010101725.GD2956@debian> References: <20181009205426.21219-1-maxime.coquelin@redhat.com> <20181009205426.21219-18-maxime.coquelin@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20181009205426.21219-18-maxime.coquelin@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v5 17/19] vhost: restrict postcopy live-migration enablement X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 10:18:45 -0000 On Tue, Oct 09, 2018 at 10:54:24PM +0200, Maxime Coquelin wrote: > Postcopy live-migration feature requires the application to > not populate the guest memory. As the vhost library cannot > prevent the application to that (e.g. preventing the > application to call mlockall()), the feature is disabled by > default. > > The application should only enable the feature if it does not > force the guest memory to be populated. > > In case the user passes the RTE_VHOST_USER_POSTCOPY_SUPPORT > flag at registration but the feature was not compiled, > registration fails. > > For the same reason, postcopy and dequeue zero copy features > are not compatible, so don't advertize postcopy support if > dequeue zero copy is requested. > > Signed-off-by: Maxime Coquelin > --- > doc/guides/prog_guide/vhost_lib.rst | 8 ++++++++ > lib/librte_vhost/rte_vhost.h | 1 + > lib/librte_vhost/socket.c | 30 ++++++++++++++++++++++++++--- > 3 files changed, 36 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst > index 77af4d775..c77df338f 100644 > --- a/doc/guides/prog_guide/vhost_lib.rst > +++ b/doc/guides/prog_guide/vhost_lib.rst > @@ -106,6 +106,14 @@ The following is an overview of some key Vhost API functions: > Enabling this flag with these Qemu version results in Qemu being blocked > when multiple queue pairs are declared. > > + - ``RTE_VHOST_USER_POSTCOPY_SUPPORT`` > + > + Postcopy live-migration support will be enabled when this flag is set. > + It is disabled by default. > + > + Enabling this flag should only be done when the calling application does > + not pre-fault the guest shared memory, otherwise migration would fail. > + > * ``rte_vhost_driver_set_features(path, features)`` > > This function sets the feature bits the vhost-user driver supports. The > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h > index 9292c89c5..d280ac420 100644 > --- a/lib/librte_vhost/rte_vhost.h > +++ b/lib/librte_vhost/rte_vhost.h > @@ -28,6 +28,7 @@ extern "C" { > #define RTE_VHOST_USER_NO_RECONNECT (1ULL << 1) > #define RTE_VHOST_USER_DEQUEUE_ZERO_COPY (1ULL << 2) > #define RTE_VHOST_USER_IOMMU_SUPPORT (1ULL << 3) > +#define RTE_VHOST_USER_POSTCOPY_SUPPORT (1ULL << 4) > > /** Protocol features. */ > #ifndef VHOST_USER_PROTOCOL_F_MQ > diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c > index 7cad5593e..4b221a805 100644 > --- a/lib/librte_vhost/socket.c > +++ b/lib/librte_vhost/socket.c > @@ -51,6 +51,8 @@ struct vhost_user_socket { > uint64_t supported_features; > uint64_t features; > > + uint64_t protocol_features; In vhost_user_set_protocol_features() in vhost_user.c, we also need to find a way to check with this field instead of VHOST_USER_PROTOCOL_FEATURES when receiving the protocol features from QEMU. > + > /* > * Device id to identify a specific backend device. > * It's set to -1 for the default software implementation. [...]