qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Yuri Benditovich <yuri.benditovich@daynix.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Yan Vugenfirer" <yan@daynix.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [RFC PATCH v2 0/3] virtio-net: graceful drop of vhost for TAP
Date: Thu, 25 Mar 2021 11:00:41 +0200	[thread overview]
Message-ID: <CAOEp5Od+jPYdmFdD3z3hVjs5t6QXgmEoOTPHO5cLVyifjmjgRQ@mail.gmail.com> (raw)
In-Reply-To: <aa33a355-5980-5ff5-7264-02d6fc7f5f9d@redhat.com>

Hi Jason,

This was discussed earlier on the previous series of patches.
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg01829.html
There were strong objections from both Daniel and Michael and I feel
that the series was rejected.
There was Michael's claim:
"We did what this patch is trying to change for years now, in
particular KVM also seems to happily disable CPU features not supported
by kernel so I wonder why we can't keep doing it, with tweaks for some
corner cases."
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03187.html
And it was Michael's question:
"Can we limit the change to when a VM is migrated in?"
https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03163.html
So I'm trying to suggest another approach:
- In case of conflicting features (for example RSS and vhost) we in
qemu we do not have enough information to prefer one or another.
- If we drop to userspace in the first set_features we say: "vhost is
less important than other requested features"
- This series keeps backward compatibility, i.e. if you start with
vhost and some features are not available - they are silently cleared.
- But in case the features are available on source machine - they are used
- In case of migration this series says: "We prefer successful
migration even if for that we need to drop to userspace"
- On the migration back to the 1st system we again work with all the
features and with vhost as all the features are available.

Thanks,
Yuri



On Thu, Mar 25, 2021 at 8:59 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/3/22 下午8:24, Yuri Benditovich 写道:
> > Allow fallback to userspace only upon migration, only for specific features
> > and only if 'vhostforce' is not requested.
> >
> > Changes from v1:
> > Patch 1 dropeed (will be submitted in another series)
> > Added device callback in case the migration should fail due to missing features
>
>
> Hi Yuri:
>
> Have a quick glance at the series. A questions is why we need to do the
> fallback only during load?
>
> I think we should do it in the device initializating. E.g when the vhost
> features can not satisfy, we should disable vhost since there.
>
> Thanks
>
>
> >
> > Yuri Benditovich (3):
> >    net: add ability to hide (disable) vhost_net
> >    virtio: introduce 'missing_features_migrated' device callback
> >    virtio-net: implement missing_features_migrated callback
> >
> >   hw/net/vhost_net.c         |  4 ++-
> >   hw/net/virtio-net.c        | 51 ++++++++++++++++++++++++++++++++++++++
> >   hw/virtio/virtio.c         |  8 ++++++
> >   include/hw/virtio/virtio.h |  8 ++++++
> >   include/net/net.h          |  1 +
> >   5 files changed, 71 insertions(+), 1 deletion(-)
> >
>


  reply	other threads:[~2021-03-25  9:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 12:24 [RFC PATCH v2 0/3] virtio-net: graceful drop of vhost for TAP Yuri Benditovich
2021-03-22 12:24 ` [RFC PATCH v2 1/3] net: add ability to hide (disable) vhost_net Yuri Benditovich
2021-03-22 12:24 ` [RFC PATCH v2 2/3] virtio: introduce 'missing_features_migrated' device callback Yuri Benditovich
2021-03-22 12:24 ` [RFC PATCH v2 3/3] virtio-net: implement missing_features_migrated callback Yuri Benditovich
2021-03-25  6:59 ` [RFC PATCH v2 0/3] virtio-net: graceful drop of vhost for TAP Jason Wang
2021-03-25  9:00   ` Yuri Benditovich [this message]
2021-03-26  7:51     ` Jason Wang
2021-03-26  9:09       ` Yuri Benditovich
2021-03-26  9:18         ` Jason Wang
2021-04-02  5:05           ` 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=CAOEp5Od+jPYdmFdD3z3hVjs5t6QXgmEoOTPHO5cLVyifjmjgRQ@mail.gmail.com \
    --to=yuri.benditovich@daynix.com \
    --cc=berrange@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yan@daynix.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 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).