On Fri, Jul 15, 2022 at 11:05 AM Eugenio Perez Martin <epere...@redhat.com> wrote: > > On Fri, Jul 15, 2022 at 10:51 AM Jason Wang <jasow...@redhat.com> wrote: > > > > On Fri, Jul 15, 2022 at 1:40 PM Eugenio Perez Martin > > <epere...@redhat.com> wrote: > > > > > > On Fri, Jul 15, 2022 at 6:03 AM Jason Wang <jasow...@redhat.com> wrote: > > > > > > > > On Fri, Jul 15, 2022 at 12:32 AM Eugenio Pérez <epere...@redhat.com> > > > > wrote: > > > > > > > > > > Since the vhost-vdpa device is exposing _F_LOG, > > > > > > > > I may miss something but I think it doesn't? > > > > > > > > > > It's at vhost_vdpa_get_features. As long as SVQ is enabled, it's > > > exposing VHOST_F_LOG_ALL. > > > > Ok, so this needs to be specified in the change log. > > Got it, I'll write some note. > > > But I'm kind of > > confused here, we do want to allow migration to work so why we disable > > it? > > >
Adding here: Without the x-svq parameter, migration is disabled unless the actual vdpa device backend supports _F_LOG_ALL by itself. There is no such thing in the Linux kernel at the moment. > With x-svq parameter, migration of simple devices with no cvq "is > possible". It has intrinsic problems like can't emit the gratuitous > arp but it's possible and traffic can continue. > > But devices with cvq require to restore the state at the destination. > That part is not implemented, so it's blocked at the moment. > > In the immediate future not all cases (as "net features") will be > available: net/vhost-net.c (or virtio-net.c?) needs to know how to > inject the state at the destination to restore the guest visible > configuration. It's simple code, but it needs to be developed. So > migration blocker is kept for these features. Hopefully, we will reach > a point where all features supported by virtio-net.c will be > supported, but the right thing to do is to merge basic ones first. > > Thanks!
