All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Jiang Wang <jiang.wang@bytedance.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	qemu-stable@nongnu.org, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Arseny Krasnov <arseny.krasnov@kaspersky.com>
Subject: Re: [PATCH] vhost-vsock: fix migration issue when seqpacket is supported
Date: Wed, 8 Sep 2021 14:48:47 +0100	[thread overview]
Message-ID: <YTi/P6IKQfNzXoaf@redhat.com> (raw)
In-Reply-To: <20210908134135.xvidtghamwahbdqk@steredhat>

On Wed, Sep 08, 2021 at 03:41:35PM +0200, Stefano Garzarella wrote:
> On Tue, Sep 07, 2021 at 03:47:56PM +0200, Stefano Garzarella wrote:
> > On Tue, Sep 07, 2021 at 02:22:24PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Sep 07, 2021 at 02:49:35PM +0200, Stefano Garzarella wrote:
> > > > Commit 1e08fd0a46 ("vhost-vsock: SOCK_SEQPACKET feature bit support")
> > > > enabled the SEQPACKET feature bit.
> > > > This commit is released with QEMU 6.1, so if we try to migrate a VM where
> > > > the host kernel supports SEQPACKET but machine type version is less than
> > > > 6.1, we get the following errors:
> > > > 
> > > >    Features 0x130000002 unsupported. Allowed features: 0x179000000
> > > >    Failed to load virtio-vhost_vsock:virtio
> > > >    error while loading state for instance 0x0 of device '0000:00:05.0/virtio-vhost_vsock'
> > > >    load of migration failed: Operation not permitted
> > > > 
> > > > Let's disable the feature bit for machine types < 6.1, adding a
> > > > `features` field to VHostVSock to simplify the handling of upcoming
> > > > features we will support.
> > > 
> > > IIUC, this will still leave migration broken for anyone migrating
> > > a >= 6.1 machine type between a kernel that supports SEQPACKET and
> > > a kernel lacking that, or vica-verca.
> > 
> > This should be true for migrating from kernel that supports SEQPACKET to
> > a kernel lacking that.
> > 
> > For vice-versa I'm not sure, since vhost_get_features() will disable
> > that feature if the host kernel doesn't support it, and the guest will
> > not have acked it.
> 
> I did some testing and the migration is only broken in the case of
> kernel 5.14+ (SEQPACKET supported) -> kernel 5.13 (SEQPACKET not supported).
> 
> Vice-versa works well because the feature is not acked.
> 
> > 
> > > 
> > > If a feature is dependant on a host kernel feature we can't turn
> > > that on automatically as part of the machine type, as we need
> > > ABI stability across migration indepdant of kernel version.
> > > 
> > 
> > How do we typically handle this?
> > 
> > I wrongly thought it was an expected behavior that migrating a guest
> > using a vhost device from a new kernel to an old one can fail if not all
> > features are supported.
> > 
> > I need to take a look at the other vhost devices.
> 
> I took a look at vhost-net and vhost-scsi and we don't seem to handle this
> case. Maybe I'm missing something...

We've never done very well at having a consistent story wrt deps
on kernel features. So I wouldn't be surprised to see differences
or omissions anywhere and people not notice the issue.

> So following your advice, the best thing would be to have this feature
> disabled by default and require the user to enable it explicitly so we are
> sure it is needed. At this point a migration to a kernel that doesn't
> support it is rightly broken.
> 
> Or is there something better we can do?
> 
> @Michael @Jason any thoughts?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2021-09-08 13:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 12:49 [PATCH] vhost-vsock: fix migration issue when seqpacket is supported Stefano Garzarella
2021-09-07 13:22 ` Daniel P. Berrangé
2021-09-07 13:47   ` Stefano Garzarella
2021-09-08 13:41     ` Stefano Garzarella
2021-09-08 13:48       ` Daniel P. Berrangé [this message]
2021-09-09  8:47   ` Michael S. Tsirkin
2021-09-09  9:02     ` Daniel P. Berrangé
2021-09-10  6:35       ` Michael S. Tsirkin
2021-09-13 12:51         ` Stefano Garzarella
2021-09-13 13:46           ` Michael S. Tsirkin
2021-09-14 10:42             ` Stefano Garzarella
2021-09-14 11:49               ` Michael S. Tsirkin

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=YTi/P6IKQfNzXoaf@redhat.com \
    --to=berrange@redhat.com \
    --cc=arseny.krasnov@kaspersky.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jiang.wang@bytedance.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=sgarzare@redhat.com \
    --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.