From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Eugenio Perez Martin <eperezma@redhat.com>,
qemu-devel@nongnu.org, si-wei.liu@oracle.com,
Liuxiangdong <liuxiangdong5@huawei.com>,
Zhu Lingshan <lingshan.zhu@intel.com>,
"Gonglei (Arei)" <arei.gonglei@huawei.com>,
alvaro.karsz@solid-run.com, Shannon Nelson <snelson@pensando.io>,
Laurent Vivier <lvivier@redhat.com>,
Harpreet Singh Anand <hanand@xilinx.com>,
Gautam Dawar <gdawar@xilinx.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Cornelia Huck <cohuck@redhat.com>, Cindy Lu <lulu@redhat.com>,
Eli Cohen <eli@mellanox.com>, Paolo Bonzini <pbonzini@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Parav Pandit <parav@mellanox.com>
Subject: Re: [RFC v2 05/13] vdpa net: add migration blocker if cannot migrate cvq
Date: Mon, 16 Jan 2023 00:23:57 -0500 [thread overview]
Message-ID: <20230116002152-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <065243b8-c93f-17e6-72cb-c1db33da6df6@redhat.com>
On Mon, Jan 16, 2023 at 11:34:20AM +0800, Jason Wang wrote:
>
> 在 2023/1/13 15:46, Eugenio Perez Martin 写道:
> > On Fri, Jan 13, 2023 at 5:25 AM Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > 在 2023/1/13 01:24, Eugenio Pérez 写道:
> > > > A vdpa net device must initialize with SVQ in order to be migratable,
> > > > and initialization code verifies conditions. If the device is not
> > > > initialized with the x-svq parameter, it will not expose _F_LOG so vhost
> > > > sybsystem will block VM migration from its initialization.
> > > >
> > > > Next patches change this. Net data VQs will be shadowed only at
> > > > migration time and vdpa net devices need to expose _F_LOG as long as it
> > > > can go to SVQ.
> > > >
> > > > Since we don't know that at initialization time but at start, add an
> > > > independent blocker at CVQ.
> > > >
> > > > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > > > ---
> > > > net/vhost-vdpa.c | 35 +++++++++++++++++++++++++++++------
> > > > 1 file changed, 29 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
> > > > index 631424d9c4..2ca93e850a 100644
> > > > --- a/net/vhost-vdpa.c
> > > > +++ b/net/vhost-vdpa.c
> > > > @@ -26,12 +26,14 @@
> > > > #include <err.h>
> > > > #include "standard-headers/linux/virtio_net.h"
> > > > #include "monitor/monitor.h"
> > > > +#include "migration/blocker.h"
> > > > #include "hw/virtio/vhost.h"
> > > >
> > > > /* Todo:need to add the multiqueue support here */
> > > > typedef struct VhostVDPAState {
> > > > NetClientState nc;
> > > > struct vhost_vdpa vhost_vdpa;
> > > > + Error *migration_blocker;
> > >
> > > Any reason we can't use the mivration_blocker in vhost_dev structure?
> > >
> > > I believe we don't need to wait until start to know we can't migrate.
> > >
> > Device migratability also depends on features that the guest acks.
>
>
> This sounds a little bit tricky, more below:
>
>
> >
> > For example, if the device does not support ASID it can be migrated as
> > long as _F_CVQ is not acked.
>
>
> The management may notice a non-consistent behavior in this case. I wonder
> if we can simply check the host features.
>
> Thanks
Yes the issue is that ack can happen after migration started.
I don't think this kind of blocker appearing during migration
is currently expected/supported well. Is it?
>
> >
> > Thanks!
> >
> > > Thanks
> > >
> > >
> > > > VHostNetState *vhost_net;
> > > >
> > > > /* Control commands shadow buffers */
> > > > @@ -433,9 +435,15 @@ static int vhost_vdpa_net_cvq_start(NetClientState *nc)
> > > > g_strerror(errno), errno);
> > > > return -1;
> > > > }
> > > > - if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_IOTLB_ASID)) ||
> > > > - !vhost_vdpa_net_valid_svq_features(v->dev->features, NULL)) {
> > > > - return 0;
> > > > + if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_IOTLB_ASID))) {
> > > > + error_setg(&s->migration_blocker,
> > > > + "vdpa device %s does not support ASID",
> > > > + nc->name);
> > > > + goto out;
> > > > + }
> > > > + if (!vhost_vdpa_net_valid_svq_features(v->dev->features,
> > > > + &s->migration_blocker)) {
> > > > + goto out;
> > > > }
> > > >
> > > > /*
> > > > @@ -455,7 +463,10 @@ static int vhost_vdpa_net_cvq_start(NetClientState *nc)
> > > > }
> > > >
> > > > if (group == cvq_group) {
> > > > - return 0;
> > > > + error_setg(&s->migration_blocker,
> > > > + "vdpa %s vq %d group %"PRId64" is the same as cvq group "
> > > > + "%"PRId64, nc->name, i, group, cvq_group);
> > > > + goto out;
> > > > }
> > > > }
> > > >
> > > > @@ -468,8 +479,15 @@ static int vhost_vdpa_net_cvq_start(NetClientState *nc)
> > > > s->vhost_vdpa.address_space_id = VHOST_VDPA_NET_CVQ_ASID;
> > > >
> > > > out:
> > > > - if (!s->vhost_vdpa.shadow_vqs_enabled) {
> > > > - return 0;
> > > > + if (s->migration_blocker) {
> > > > + Error *errp = NULL;
> > > > + r = migrate_add_blocker(s->migration_blocker, &errp);
> > > > + if (unlikely(r != 0)) {
> > > > + g_clear_pointer(&s->migration_blocker, error_free);
> > > > + error_report_err(errp);
> > > > + }
> > > > +
> > > > + return r;
> > > > }
> > > >
> > > > s0 = vhost_vdpa_net_first_nc_vdpa(s);
> > > > @@ -513,6 +531,11 @@ static void vhost_vdpa_net_cvq_stop(NetClientState *nc)
> > > > vhost_vdpa_cvq_unmap_buf(&s->vhost_vdpa, s->status);
> > > > }
> > > >
> > > > + if (s->migration_blocker) {
> > > > + migrate_del_blocker(s->migration_blocker);
> > > > + g_clear_pointer(&s->migration_blocker, error_free);
> > > > + }
> > > > +
> > > > vhost_vdpa_net_client_stop(nc);
> > > > }
> > > >
next prev parent reply other threads:[~2023-01-16 5:48 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 17:24 [RFC v2 00/13] Dinamycally switch to vhost shadow virtqueues at vdpa net migration Eugenio Pérez
2023-01-12 17:24 ` [RFC v2 01/13] vdpa: fix VHOST_BACKEND_F_IOTLB_ASID flag check Eugenio Pérez
2023-01-13 3:12 ` Jason Wang
2023-01-13 6:42 ` Eugenio Perez Martin
2023-01-16 3:01 ` Jason Wang
2023-01-12 17:24 ` [RFC v2 02/13] vdpa net: move iova tree creation from init to start Eugenio Pérez
2023-01-13 3:53 ` Jason Wang
2023-01-13 7:28 ` Eugenio Perez Martin
2023-01-16 3:05 ` Jason Wang
2023-01-16 9:14 ` Eugenio Perez Martin
2023-01-17 4:30 ` Jason Wang
2023-01-12 17:24 ` [RFC v2 03/13] vdpa: copy cvq shadow_data from data vqs, not from x-svq Eugenio Pérez
2023-01-12 17:24 ` [RFC v2 04/13] vdpa: rewind at get_base, not set_base Eugenio Pérez
2023-01-13 4:09 ` Jason Wang
2023-01-13 7:40 ` Eugenio Perez Martin
2023-01-16 3:32 ` Jason Wang
2023-01-16 9:53 ` Eugenio Perez Martin
2023-01-17 4:38 ` Jason Wang
2023-01-17 6:57 ` Eugenio Perez Martin
2023-01-12 17:24 ` [RFC v2 05/13] vdpa net: add migration blocker if cannot migrate cvq Eugenio Pérez
2023-01-13 4:24 ` Jason Wang
2023-01-13 7:46 ` Eugenio Perez Martin
2023-01-16 3:34 ` Jason Wang
2023-01-16 5:23 ` Michael S. Tsirkin [this message]
2023-01-16 9:33 ` Eugenio Perez Martin
2023-01-17 5:42 ` Jason Wang
2023-01-12 17:24 ` [RFC v2 06/13] vhost: delay set_vring_ready after DRIVER_OK Eugenio Pérez
2023-01-13 4:36 ` Jason Wang
2023-01-13 8:19 ` Eugenio Perez Martin
2023-01-13 9:51 ` Stefano Garzarella
2023-01-13 10:03 ` Eugenio Perez Martin
2023-01-13 10:37 ` Stefano Garzarella
2023-01-17 15:15 ` Maxime Coquelin
2023-01-16 6:36 ` Jason Wang
2023-01-16 16:16 ` Eugenio Perez Martin
2023-01-17 5:36 ` Jason Wang
2023-01-12 17:24 ` [RFC v2 07/13] vdpa: " Eugenio Pérez
2023-01-12 17:24 ` [RFC v2 08/13] vdpa: Negotiate _F_SUSPEND feature Eugenio Pérez
2023-01-13 4:39 ` Jason Wang
2023-01-13 8:45 ` Eugenio Perez Martin
2023-01-16 6:48 ` Jason Wang
2023-01-16 16:17 ` Eugenio Perez Martin
2023-01-12 17:24 ` [RFC v2 09/13] vdpa: add feature_log parameter to vhost_vdpa Eugenio Pérez
2023-01-12 17:24 ` [RFC v2 10/13] vdpa net: allow VHOST_F_LOG_ALL Eugenio Pérez
2023-01-13 4:42 ` Jason Wang
2023-01-12 17:24 ` [RFC v2 11/13] vdpa: add vdpa net migration state notifier Eugenio Pérez
2023-01-13 4:54 ` Jason Wang
2023-01-13 9:00 ` Eugenio Perez Martin
2023-01-16 6:51 ` Jason Wang
2023-01-16 15:21 ` Eugenio Perez Martin
2023-01-17 9:58 ` Dr. David Alan Gilbert
2023-01-17 10:23 ` Eugenio Perez Martin
2023-01-17 12:54 ` Dr. David Alan Gilbert
2023-02-02 1:52 ` Si-Wei Liu
2023-02-02 15:28 ` Eugenio Perez Martin
2023-02-04 2:03 ` Si-Wei Liu
2023-02-13 9:47 ` Eugenio Perez Martin
2023-02-13 22:36 ` Si-Wei Liu
2023-02-14 18:51 ` Eugenio Perez Martin
2023-02-12 14:31 ` Eli Cohen
2023-01-12 17:24 ` [RFC v2 12/13] vdpa: preemptive kick at enable Eugenio Pérez
2023-01-13 2:31 ` Jason Wang
2023-01-13 3:25 ` Zhu, Lingshan
2023-01-13 3:39 ` Jason Wang
2023-01-13 9:06 ` Eugenio Perez Martin
2023-01-16 7:02 ` Jason Wang
2023-02-02 16:55 ` Eugenio Perez Martin
2023-02-02 0:56 ` Si-Wei Liu
2023-02-02 16:53 ` Eugenio Perez Martin
2023-02-04 11:04 ` Si-Wei Liu
2023-02-05 10:00 ` Michael S. Tsirkin
2023-02-06 5:08 ` Si-Wei Liu
2023-01-12 17:24 ` [RFC v2 13/13] vdpa: Conditionally expose _F_LOG in vhost_net devices Eugenio Pérez
2023-02-02 1:00 ` [RFC v2 00/13] Dinamycally switch to vhost shadow virtqueues at vdpa net migration Si-Wei Liu
2023-02-02 11:27 ` Eugenio Perez Martin
2023-02-03 5:08 ` Si-Wei Liu
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=20230116002152-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alvaro.karsz@solid-run.com \
--cc=arei.gonglei@huawei.com \
--cc=cohuck@redhat.com \
--cc=eli@mellanox.com \
--cc=eperezma@redhat.com \
--cc=gdawar@xilinx.com \
--cc=hanand@xilinx.com \
--cc=jasowang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=liuxiangdong5@huawei.com \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=parav@mellanox.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=si-wei.liu@oracle.com \
--cc=snelson@pensando.io \
--cc=stefanha@redhat.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.