From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <maxime.coquelin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dpdk.org (Postfix) with ESMTP id 7B6311B4E3;
Wed, 10 Oct 2018 12:23:49 +0200 (CEST)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
[10.5.11.12])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 90DC83082A43;
Wed, 10 Oct 2018 10:23:48 +0000 (UTC)
Received: from [10.36.112.48] (ovpn-112-48.ams2.redhat.com [10.36.112.48])
by smtp.corp.redhat.com (Postfix) with ESMTPS id C0C6068DA7;
Wed, 10 Oct 2018 10:23:41 +0000 (UTC)
To: Tiwei Bie <tiwei.bie@intel.com>
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
References: <20181009205426.21219-1-maxime.coquelin@redhat.com>
<20181009205426.21219-18-maxime.coquelin@redhat.com>
<20181010101725.GD2956@debian>
From: Maxime Coquelin <maxime.coquelin@redhat.com>
Message-ID: <88027651-738e-4140-4d59-4987443c52be@redhat.com>
Date: Wed, 10 Oct 2018 12:23:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181010101725.GD2956@debian>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.45]); Wed, 10 Oct 2018 10:23:48 +0000 (UTC)
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 10:23:49 -0000
On 10/10/2018 12:17 PM, Tiwei Bie wrote:
> 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 <maxime.coquelin@redhat.com>
>> ---
>> 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.
Makes sense.
Something like calling rte_vhost_driver_get_protocol_features() there
and use result instead of VHOST_USER_PROTOCOL_FEATURES should do the
trick.
>> +
>> /*
>> * Device id to identify a specific backend device.
>> * It's set to -1 for the default software implementation.
> [...]
>