Re: [dpdk-dev] [PATCH v5 17/19] vhost: restrict postcopy live-migration enablement

[Maxime Coquelin <maxime.coquelin@redhat.com>]

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.
> [...]
>