All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Thibaut Collet <thibaut.collet@6wind.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest
Date: Thu, 11 Jun 2015 13:39:53 +0800	[thread overview]
Message-ID: <55791F29.6060000@redhat.com> (raw)
In-Reply-To: <CABUUfwOMHZivKNyeGafdjdRkYBWHfa6TB5rfOinDAFz+_TwEkA@mail.gmail.com>



On 06/11/2015 04:25 AM, Thibaut Collet wrote:
> Yes backend can save everything to be able to send the rarp alone
> after a live migration.

Yes, but still need a mechanism to notify the backend of migration
completion from qemu side if GUEST_ANNOUNCE is not negotiated.

> Main purpose of this patch is to answer to the point raise by Jason on
> the previous version of my patch:
> > Yes, your patch works well for recent drivers. But the problem is legacy
> > guest/driver without VIRTIO_NET_F_GUEST_ANNOUNCE. In this case there
> > will be no GARP sent after migration.
>
> If Jason is OK with this solution this patch can be forgotten.
>

I prefer to do this in backend since it looks easier.

Thanks

> Maybe, to warn user of this issue if the backend does not send the
> rarp, it can be useful to keep the warn message of the previous patch:
> > +        fprintf(stderr,
> > +                "Warning: Guest with no VIRTIO_NET_F_GUEST_ANNOUNCE support. RARP
> must be sent by vhost-user backend\n");
> > +        fflush(stderr);
> with a static bool to display this message only one time to limit the
> number of message ?
>
> On Wed, Jun 10, 2015 at 6:00 PM, Michael S. Tsirkin <mst@redhat.com
> <mailto:mst@redhat.com>> wrote:
>
>     On Wed, Jun 10, 2015 at 05:48:47PM +0200, Thibaut Collet wrote:
>     > I have involved QEMU because QEMU prepares the rarp. I agree
>     that backend has
>     > probably all the information to do that.
>     > But backend does not know if the guest supports
>     the VIRTIO_NET_F_GUEST_ANNOUNCE
>
>     Why not?  Backend has the acked feature mask.
>
>
>     > and will send a useless rarp.
>     > Maybe this duplication of requests is not very important and in
>     this case this
>     > patch is not mandatory.
>     >
>     > On Wed, Jun 10, 2015 at 5:34 PM, Michael S. Tsirkin
>     <mst@redhat.com <mailto:mst@redhat.com>> wrote:
>     >
>     >     On Wed, Jun 10, 2015 at 03:43:03PM +0200, Thibaut Collet wrote:
>     >     > In case of live migration with legacy guest (without
>     >     VIRTIO_NET_F_GUEST_ANNOUNCE)
>     >     > a message is added between QEMU and the vhost client/backend.
>     >     > This message provides the RARP content, prepared by QEMU,
>     to the vhost
>     >     > client/backend.
>     >     > The vhost client/backend is responsible to send the RARP.
>     >     >
>     >     > Signed-off-by: Thibaut Collet <thibaut.collet@6wind.com
>     <mailto:thibaut.collet@6wind.com>>
>     >     > ---
>     >     >  docs/specs/vhost-user.txt   |   16 ++++++++++++++++
>     >     >  hw/net/vhost_net.c          |    8 ++++++++
>     >     >  hw/virtio/vhost-user.c      |   11 ++++++++++-
>     >     >  linux-headers/linux/vhost.h |    9 +++++++++
>     >     >  4 files changed, 43 insertions(+), 1 deletion(-)
>     >     >
>     >     > diff --git a/docs/specs/vhost-user.txt
>     b/docs/specs/vhost-user.txt
>     >     > index 2c8e934..ef5d475 100644
>     >     > --- a/docs/specs/vhost-user.txt
>     >     > +++ b/docs/specs/vhost-user.txt
>     >     > @@ -97,6 +97,7 @@ typedef struct VhostUserMsg {
>     >     >          uint64_t u64;
>     >     >          struct vhost_vring_state state;
>     >     >          struct vhost_vring_addr addr;
>     >     > +        struct vhost_inject_rarp rarp;
>     >     >          VhostUserMemory memory;
>     >     >      };
>     >     >  } QEMU_PACKED VhostUserMsg;
>     >     > @@ -132,6 +133,12 @@ Multi queue support
>     >     >  The protocol supports multiple queues by setting all
>     index fields in the
>     >     sent
>     >     >  messages to a properly calculated value.
>     >     >
>     >     > +Live migration support
>     >     > +----------------------
>     >     > +The protocol supports live migration. GARP from the
>     migrated guest is
>     >     done
>     >     > +through the VIRTIO_NET_F_GUEST_ANNOUNCE mechanism for
>     guest that
>     >     supports it or
>     >     > +through RARP.
>     >     > +
>     >     >  Message types
>     >     >  -------------
>     >     >
>     >     > @@ -269,3 +276,12 @@ Message types
>     >     >        Bits (0-7) of the payload contain the vring index.
>     Bit 8 is the
>     >     >        invalid FD flag. This flag is set when there is no
>     file descriptor
>     >     >        in the ancillary data.
>     >     > +
>     >     > + * VHOST_USER_NET_INJECT_RARP
>     >     > +
>     >     > +      Id: 15
>     >     > +      Master payload: rarp content
>     >     > +
>     >     > +      Provide the RARP message to send to the guest after
>     a live
>     >     migration. This
>     >     > +      message is sent only for guest that does not support
>     >     > +      VIRTIO_NET_F_GUEST_ANNOUNCE.
>     >
>     >     I don't see why this is needed.
>     >     Can't backend simply send rarp itself?
>     >     Why do we need to involve QEMU?
>     >
>     >
>     >
>     >     > diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
>     >     > index 4a42325..f66d48d 100644
>     >     > --- a/hw/net/vhost_net.c
>     >     > +++ b/hw/net/vhost_net.c
>     >     > @@ -369,10 +369,18 @@ void vhost_net_stop(VirtIODevice *dev,
>     >     NetClientState *ncs,
>     >     >
>     >     >  void vhost_net_inject_rarp(struct vhost_net *net, const
>     uint8_t *buf,
>     >     size_t size)
>     >     >  {
>     >     > +    struct vhost_inject_rarp inject_rarp;
>     >     > +    memcpy(&inject_rarp.rarp, buf, size);
>     >     > +
>     >     >      if ((net->dev.acked_features & (1 <<
>     VIRTIO_NET_F_GUEST_ANNOUNCE)) =
>     >     = 0) {
>     >     > +        const VhostOps *vhost_ops = net->dev.vhost_ops;
>     >     > +        int r;
>     >     > +
>     >     >          fprintf(stderr,
>     >     >                  "Warning: Guest with no
>     VIRTIO_NET_F_GUEST_ANNOUNCE
>     >     support. RARP must be sent by vhost-user backend\n");
>     >     >          fflush(stderr);
>     >     > +        r = vhost_ops->vhost_call(&net->dev,
>     VHOST_NET_INJECT_RARP, &
>     >     inject_rarp);
>     >     > +        assert(r >= 0);
>     >     >      }
>     >     >  }
>     >     >
>     >     > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
>     >     > index d6f2163..2e752ab 100644
>     >     > --- a/hw/virtio/vhost-user.c
>     >     > +++ b/hw/virtio/vhost-user.c
>     >     > @@ -41,6 +41,7 @@ typedef enum VhostUserRequest {
>     >     >      VHOST_USER_SET_VRING_KICK = 12,
>     >     >      VHOST_USER_SET_VRING_CALL = 13,
>     >     >      VHOST_USER_SET_VRING_ERR = 14,
>     >     > +    VHOST_USER_NET_INJECT_RARP = 15,
>     >     >      VHOST_USER_MAX
>     >     >  } VhostUserRequest;
>     >     >
>     >     > @@ -70,6 +71,7 @@ typedef struct VhostUserMsg {
>     >     >          uint64_t u64;
>     >     >          struct vhost_vring_state state;
>     >     >          struct vhost_vring_addr addr;
>     >     > +        struct vhost_inject_rarp rarp;
>     >     >          VhostUserMemory memory;
>     >     >      };
>     >     >  } QEMU_PACKED VhostUserMsg;
>     >     > @@ -104,7 +106,8 @@ static unsigned long int
>     ioctl_to_vhost_user_request
>     >     [VHOST_USER_MAX] = {
>     >     >      VHOST_GET_VRING_BASE,   /* VHOST_USER_GET_VRING_BASE */
>     >     >      VHOST_SET_VRING_KICK,   /* VHOST_USER_SET_VRING_KICK */
>     >     >      VHOST_SET_VRING_CALL,   /* VHOST_USER_SET_VRING_CALL */
>     >     > -    VHOST_SET_VRING_ERR     /* VHOST_USER_SET_VRING_ERR */
>     >     > +    VHOST_SET_VRING_ERR,    /* VHOST_USER_SET_VRING_ERR */
>     >     > +    VHOST_NET_INJECT_RARP   /* VHOST_USER_NET_INJECT_RARP */
>     >     >  };
>     >     >
>     >     >  static VhostUserRequest
>     vhost_user_request_translate(unsigned long int
>     >     request)
>     >     > @@ -287,6 +290,12 @@ static int vhost_user_call(struct
>     vhost_dev *dev,
>     >     unsigned long int request,
>     >     >              msg.u64 |= VHOST_USER_VRING_NOFD_MASK;
>     >     >          }
>     >     >          break;
>     >     > +
>     >     > +    case VHOST_NET_INJECT_RARP:
>     >     > +        memcpy(&msg.rarp, arg, sizeof(struct
>     vhost_inject_rarp));
>     >     > +        msg.size = sizeof(struct vhost_inject_rarp);
>     >     > +        break;
>     >     > +
>     >     >      default:
>     >     >          error_report("vhost-user trying to send unhandled
>     ioctl");
>     >     >          return -1;
>     >     > diff --git a/linux-headers/linux/vhost.h
>     b/linux-headers/linux/vhost.h
>     >     > index c656f61..1920134 100644
>     >     > --- a/linux-headers/linux/vhost.h
>     >     > +++ b/linux-headers/linux/vhost.h
>     >     > @@ -63,6 +63,10 @@ struct vhost_memory {
>     >     >       struct vhost_memory_region regions[0];
>     >     >  };
>     >     >
>     >     > +struct vhost_inject_rarp {
>     >     > +     __u8 rarp[60];
>     >     > +};
>     >     > +
>     >     >  /* ioctls */
>     >     >
>     >     >  #define VHOST_VIRTIO 0xAF
>     >     > @@ -121,6 +125,11 @@ struct vhost_memory {
>     >     >   * device.  This can be used to stop the ring (e.g. for
>     migration). */
>     >     >  #define VHOST_NET_SET_BACKEND _IOW(VHOST_VIRTIO, 0x30, struct
>     >     vhost_vring_file)
>     >     >
>     >     > +/* Inject a RARP in case of live migration for guest that
>     does not
>     >     support
>     >     > + * VIRTIO_NET_F_GUEST_ANNOUNCE */
>     >     > +#define VHOST_NET_INJECT_RARP _IOW(VHOST_VIRTIO, 0x31, struct
>     >     vhost_inject_rarp)
>     >     > +
>     >     > +
>     >     >  /* Feature bits */
>     >     >  /* Log all write descriptors. Can be changed while device
>     is active. */
>     >     >  #define VHOST_F_LOG_ALL 26
>     >     > --
>     >     > 1.7.10.4
>     >
>     >
>
>

  parent reply	other threads:[~2015-06-11  5:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 13:43 [Qemu-devel] [PATCH v3 0/2] Add live migration for vhost user Thibaut Collet
2015-06-10 13:43 ` [Qemu-devel] [PATCH v3 1/2] vhost user: add support of live migration Thibaut Collet
2015-06-10 13:52   ` Michael S. Tsirkin
2015-06-10 14:22     ` Thibaut Collet
2015-06-10 14:27       ` Michael S. Tsirkin
2015-06-10 15:24         ` Thibaut Collet
2015-06-10 15:34     ` Stefan Hajnoczi
2015-06-23  6:01   ` Michael S. Tsirkin
2015-06-10 13:43 ` [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest Thibaut Collet
2015-06-10 15:34   ` Michael S. Tsirkin
2015-06-10 15:48     ` Thibaut Collet
2015-06-10 16:00       ` Michael S. Tsirkin
2015-06-10 20:25         ` Thibaut Collet
2015-06-10 20:50           ` Michael S. Tsirkin
2015-06-11  5:34             ` Thibaut Collet
2015-06-11  5:39           ` Jason Wang [this message]
2015-06-11  5:49             ` Thibaut Collet
2015-06-11  5:54               ` Jason Wang
2015-06-11 10:38                 ` Michael S. Tsirkin
2015-06-11 12:10                   ` Thibaut Collet
2015-06-11 12:13                     ` Michael S. Tsirkin
2015-06-11 12:33                       ` Thibaut Collet
2015-06-12  7:55                       ` Jason Wang
2015-06-12 11:53                         ` Thibaut Collet
2015-06-12 14:28                         ` Michael S. Tsirkin
2015-06-15  7:43                           ` Jason Wang
2015-06-15  8:44                             ` Michael S. Tsirkin
2015-06-15 12:12                               ` Thibaut Collet
2015-06-15 12:45                                 ` Michael S. Tsirkin
2015-06-15 13:04                                   ` Thibaut Collet
2015-06-16  5:29                                 ` Jason Wang
2015-06-16  7:24                                   ` Thibaut Collet
2015-06-16  8:05                                     ` Jason Wang
2015-06-16  8:16                                       ` Thibaut Collet
2015-06-17  4:16                                         ` Jason Wang
2015-06-17  6:42                                           ` Michael S. Tsirkin
2015-06-17  7:05                                             ` Thibaut Collet
2015-06-18 15:16                                       ` Thibaut Collet
2015-06-23  2:12                                         ` Jason Wang
2015-06-23  5:49                                           ` Michael S. Tsirkin
2015-06-24  8:31                                             ` Jason Wang
2015-06-24 11:05                                               ` Michael S. Tsirkin
2015-06-25  9:59                                                 ` Jason Wang
2015-06-25 11:01                                                   ` Thibaut Collet
2015-06-25 12:53                                                     ` Michael S. Tsirkin
2015-06-25 14:22                                                       ` Thibaut Collet
2015-06-26  4:06                                                         ` Jason Wang
2015-06-16  3:35                               ` Jason Wang

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=55791F29.6060000@redhat.com \
    --to=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thibaut.collet@6wind.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.