qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Liu, Changpeng" <changpeng.liu@intel.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] vhost-user: back SET/GET_CONFIG requests with a protocol feature
Date: Thu, 29 Mar 2018 10:07:05 +0200	[thread overview]
Message-ID: <b360bc28-fa90-b8f1-d4a2-12ad3c51a492@redhat.com> (raw)
In-Reply-To: <FF7FC980937D6342B9D289F5F3C7C2625B62571B@SHSMSX103.ccr.corp.intel.com>



On 03/29/2018 10:05 AM, Liu, Changpeng wrote:
> 
> 
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>> Sent: Thursday, March 29, 2018 3:56 PM
>> To: Liu, Changpeng <changpeng.liu@intel.com>; mst@redhat.com;
>> marcandre.lureau@redhat.com; qemu-devel@nongnu.org
>> Subject: Re: [PATCH v2 2/2] vhost-user: back SET/GET_CONFIG requests with a
>> protocol feature
>>
>>
>>
>> On 03/29/2018 02:57 AM, Liu, Changpeng wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>> Sent: Thursday, March 29, 2018 3:28 AM
>>>> To: mst@redhat.com; Liu, Changpeng <changpeng.liu@intel.com>;
>>>> marcandre.lureau@redhat.com; qemu-devel@nongnu.org
>>>> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>> Subject: [PATCH v2 2/2] vhost-user: back SET/GET_CONFIG requests with a
>>>> protocol feature
>>>>
>>>> Without a dedicated protocol feature, QEMU cannot know whether
>>>> the backend can handle VHOST_USER_SET_CONFIG and
>>>> VHOST_USER_GET_CONFIG messages.
>>>>
>>>> This patch adds a protocol feature that is only advertised by
>>>> QEMU if the device implements the config ops. Vhost user init
>>>> fails if the device support the feature but the backend doesn't.
>>>>
>>>> The backend should only send VHOST_USER_SLAVE_CONFIG_CHANGE_MSG
>>>> requests if the protocol feature has been negotiated.
>>>>
>>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>
>>> Passed our own vhost-user-blk target with the patch, I can submit a fix to
>> QEMU vhost-user-blk example
>>> after this commit.
>>>
>>> Tested-by: Changpeng Liu <changpeng.liu@intel.com>
>>
>> Thanks for having tested, and for proposing to implement the example
>> part. Just notice I forgot to apply your Tested-by on the series.
> I have added the fix to the example based on your patch, I'm wondering
> I can send it out for review now or wait for your commit being merged ?

I think you can post, and add a note in comments that it depends on my
series.

Thanks,
Maxime

>>
>> Maxime
>>>> ---
>>>>    docs/interop/vhost-user.txt | 21 ++++++++++++---------
>>>>    hw/virtio/vhost-user.c      | 22 ++++++++++++++++++++++
>>>>    2 files changed, 34 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
>>>> index c058c407df..534caab18a 100644
>>>> --- a/docs/interop/vhost-user.txt
>>>> +++ b/docs/interop/vhost-user.txt
>>>> @@ -379,6 +379,7 @@ Protocol features
>>>>    #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN   6
>>>>    #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7
>>>>    #define VHOST_USER_PROTOCOL_F_PAGEFAULT      8
>>>> +#define VHOST_USER_PROTOCOL_F_CONFIG         9
>>>>
>>>>    Master message types
>>>>    --------------------
>>>> @@ -664,7 +665,8 @@ Master message types
>>>>          Master payload: virtio device config space
>>>>          Slave payload: virtio device config space
>>>>
>>>> -      Submitted by the vhost-user master to fetch the contents of the virtio
>>>> +      When VHOST_USER_PROTOCOL_F_CONFIG is negotiated, this message is
>>>> +      submitted by the vhost-user master to fetch the contents of the virtio
>>>>          device configuration space, vhost-user slave's payload size MUST match
>>>>          master's request, vhost-user slave uses zero length of payload to
>>>>          indicate an error to vhost-user master. The vhost-user master may
>>>> @@ -677,7 +679,8 @@ Master message types
>>>>          Master payload: virtio device config space
>>>>          Slave payload: N/A
>>>>
>>>> -      Submitted by the vhost-user master when the Guest changes the virtio
>>>> +      When VHOST_USER_PROTOCOL_F_CONFIG is negotiated, this message is
>>>> +      submitted by the vhost-user master when the Guest changes the virtio
>>>>          device configuration space and also can be used for live migration
>>>>          on the destination host. The vhost-user slave must check the flags
>>>>          field, and slaves MUST NOT accept SET_CONFIG for read-only
>>>> @@ -766,13 +769,13 @@ Slave message types
>>>>         Slave payload: N/A
>>>>         Master payload: N/A
>>>>
>>>> -     Vhost-user slave sends such messages to notify that the virtio device's
>>>> -     configuration space has changed, for those host devices which can
>> support
>>>> -     such feature, host driver can send VHOST_USER_GET_CONFIG message to
>>>> slave
>>>> -     to get the latest content. If VHOST_USER_PROTOCOL_F_REPLY_ACK is
>>>> -     negotiated, and slave set the VHOST_USER_NEED_REPLY flag, master must
>>>> -     respond with zero when operation is successfully completed, or non-zero
>>>> -     otherwise.
>>>> +     When VHOST_USER_PROTOCOL_F_CONFIG is negotiated, vhost-user slave
>>>> sends
>>>> +     such messages to notify that the virtio device's configuration space has
>>>> +     changed, for those host devices which can support such feature, host
>>>> +     driver can send VHOST_USER_GET_CONFIG message to slave to get the
>> latest
>>>> +     content. If VHOST_USER_PROTOCOL_F_REPLY_ACK is negotiated, and
>> slave
>>>> set
>>>> +     the VHOST_USER_NEED_REPLY flag, master must respond with zero when
>>>> +     operation is successfully completed, or non-zero otherwise.
>>>>
>>>>    VHOST_USER_PROTOCOL_F_REPLY_ACK:
>>>>    -------------------------------
>>>> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
>>>> index 44aea5c0a8..cc8a24aa31 100644
>>>> --- a/hw/virtio/vhost-user.c
>>>> +++ b/hw/virtio/vhost-user.c
>>>> @@ -46,6 +46,7 @@ enum VhostUserProtocolFeature {
>>>>        VHOST_USER_PROTOCOL_F_CROSS_ENDIAN = 6,
>>>>        VHOST_USER_PROTOCOL_F_CRYPTO_SESSION = 7,
>>>>        VHOST_USER_PROTOCOL_F_PAGEFAULT = 8,
>>>> +    VHOST_USER_PROTOCOL_F_CONFIG = 9,
>>>>        VHOST_USER_PROTOCOL_F_MAX
>>>>    };
>>>>
>>>> @@ -1211,6 +1212,17 @@ static int vhost_user_init(struct vhost_dev *dev,
>> void
>>>> *opaque)
>>>>
>>>>            dev->protocol_features =
>>>>                protocol_features & VHOST_USER_PROTOCOL_FEATURE_MASK;
>>>> +
>>>> +        if (!dev->config_ops || !dev->config_ops->vhost_dev_config_notifier) {
>>>> +            /* Dont acknowledge CONFIG feature if device doesn't support it */
>>>> +            dev->protocol_features &= ~(1ULL <<
>>>> VHOST_USER_PROTOCOL_F_CONFIG);
>>>> +        } else if (!(protocol_features &
>>>> +                    (1ULL << VHOST_USER_PROTOCOL_F_CONFIG))) {
>>>> +            error_report("Device expects VHOST_USER_PROTOCOL_F_CONFIG "
>>>> +                    "but backend does not support it.");
>>>> +            return -1;
>>>> +        }
>>>> +
>>>>            err = vhost_user_set_protocol_features(dev, dev->protocol_features);
>>>>            if (err < 0) {
>>>>                return err;
>>>> @@ -1405,6 +1417,11 @@ static int vhost_user_get_config(struct vhost_dev
>>>> *dev, uint8_t *config,
>>>>            .hdr.size = VHOST_USER_CONFIG_HDR_SIZE + config_len,
>>>>        };
>>>>
>>>> +    if (!virtio_has_feature(dev->protocol_features,
>>>> +                VHOST_USER_PROTOCOL_F_CONFIG)) {
>>>> +        return -1;
>>>> +    }
>>>> +
>>>>        if (config_len > VHOST_USER_MAX_CONFIG_SIZE) {
>>>>            return -1;
>>>>        }
>>>> @@ -1448,6 +1465,11 @@ static int vhost_user_set_config(struct vhost_dev
>>>> *dev, const uint8_t *data,
>>>>            .hdr.size = VHOST_USER_CONFIG_HDR_SIZE + size,
>>>>        };
>>>>
>>>> +    if (!virtio_has_feature(dev->protocol_features,
>>>> +                VHOST_USER_PROTOCOL_F_CONFIG)) {
>>>> +        return -1;
>>>> +    }
>>>> +
>>>>        if (reply_supported) {
>>>>            msg.hdr.flags |= VHOST_USER_NEED_REPLY_MASK;
>>>>        }
>>>> --
>>>> 2.14.3
>>>

      reply	other threads:[~2018-03-29  8:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 19:27 [Qemu-devel] [PATCH v2 0/2] vhost-user: Back SET/GET_CONFIG with a protocol feature Maxime Coquelin
2018-03-28 19:27 ` [Qemu-devel] [PATCH v2 1/2] vhost-user-blk: set config ops before vhost-user init Maxime Coquelin
2018-03-29  0:53   ` Liu, Changpeng
2018-03-29  7:43     ` Maxime Coquelin
2018-03-28 19:28 ` [Qemu-devel] [PATCH v2 2/2] vhost-user: back SET/GET_CONFIG requests with a protocol feature Maxime Coquelin
2018-03-29  0:57   ` Liu, Changpeng
2018-03-29  7:55     ` Maxime Coquelin
2018-03-29  8:05       ` Liu, Changpeng
2018-03-29  8:07         ` Maxime Coquelin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b360bc28-fa90-b8f1-d4a2-12ad3c51a492@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=changpeng.liu@intel.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).