From: "Daniel P. Berrangé" <email@example.com>
To: Vitaly Kuznetsov <firstname.lastname@example.org>
Cc: Eduardo Habkost <email@example.com>,
"Michael S. Tsirkin" <firstname.lastname@example.org>,
Richard Henderson <email@example.com>,
"Dr. David Alan Gilbert" <firstname.lastname@example.org>,
Paolo Bonzini <email@example.com>
Subject: Re: [PATCH 0/2] i386: Fix interrupt based Async PF enablement
Date: Wed, 21 Apr 2021 10:37:31 +0100 [thread overview]
Message-ID: <YH/yW+mVgvGHXXmW@redhat.com> (raw)
On Wed, Apr 21, 2021 at 11:29:45AM +0200, Vitaly Kuznetsov wrote:
> Daniel P. Berrangé <firstname.lastname@example.org> writes:
> > On Wed, Apr 21, 2021 at 10:38:06AM +0200, Vitaly Kuznetsov wrote:
> >> Eduardo Habkost <email@example.com> writes:
> >> > On Thu, Apr 15, 2021 at 08:14:30PM +0100, Dr. David Alan Gilbert wrote:
> >> >> * Paolo Bonzini (firstname.lastname@example.org) wrote:
> >> >> > On 06/04/21 13:42, Vitaly Kuznetsov wrote:
> >> >> > > older machine types are still available (I disable it for <= 5.1 but we
> >> >> > > can consider disabling it for 5.2 too). The feature is upstream since
> >> >> > > Linux 5.8, I know that QEMU supports much older kernels but this doesn't
> >> >> > > probably mean that we can't enable new KVM PV features unless all
> >> >> > > supported kernels have it, we'd have to wait many years otherwise.
> >> >> >
> >> >> > Yes, this is a known problem in fact. :( In 6.0 we even support RHEL 7,
> >> >> > though that will go away in 6.1.
> >> >> >
> >> >> > We should take the occasion of dropping RHEL7 to be clearer about which
> >> >> > kernels are supported.
> >> >>
> >> >> It would be nice to be able to define sets of KVM functonality that we
> >> >> can either start given machine types with, or provide a separate switch
> >> >> to limit kvm functionality back to some defined point. We do trip over
> >> >> the same things pretty regularly when accidentally turning on new
> >> >> features.
> >> >
> >> > The same idea can apply to the hyperv=on stuff Vitaly is working
> >> > on. Maybe we should consider making a generic version of the
> >> > s390x FeatGroup code, use it to define convenient sets of KVM and
> >> > hyperv features.
> >> True, the more I look at PV features enablement, the more I think that
> >> we're missing something important in the logic. All machine types we
> >> have are generally suposed to work with the oldest supported kernel so
> >> we should wait many years before enabling some of the new PV features
> >> (KVM or Hyper-V) by default.
> >> This also links to our parallel discussion regarding migration
> >> policies. Currently, we can't enable PV features by default based on
> >> their availability on the host because of migration, the set may differ
> >> on the destination host. What if we introduce (and maybe even switch to
> >> it by default) something like
> >> -migratable opportunistic (stupid name, I know)
> >> which would allow to enable all features supported by the source host
> >> and then somehow checking that the destination host has them all. This
> >> would effectively mean that it is possible to migrate a VM to a
> >> same-or-newer software (both kernel an QEMU) but not the other way
> >> around. This may be a reasonable choice.
> > I don't think this is usable in pratice. Any large cloud or data center
> > mgmt app using QEMU relies on migration, so can't opportunistically
> > use arbitrary new features. They can only use features in the oldest
> > kernel their deployment cares about. This can be newer than the oldest
> > that QEMU supports, but still older than the newest that exists.
> > ie we have situation where:
> > - QEMU upstream minimum host is version 7
> > - Latest possible host is version 45
> > - A particular deployment has a mixture of hosts at version 24 and 37
> > "-migratable opportunistic" would let QEMU use features from version 37
> > despite the deployment needing compatibility with host version 24 still.
> True; I was not really thinking about 'big' clouds/data centers, these
> should have enough resources to carefully set all the required features
> and not rely on the 'default'. My thoughts were around using migration
> for host upgrade on smaller (several hosts) deployments and in this case
> it's probably fairly reasonable to require to start with the oldest host
> and upgrade them all if getting new features is one of the upgrade goals.
> > It is almost as if we need to have a way to explicitly express a minimum
> > required host version that VM requires compatibility with, so deployments
> > can set their own baseline that is newer than QEMU minimum.
> Yes, maybe, but setting the baseline is also a non-trivial task:
> e.g. how would users know which PV features they can enable without
> going through Linux kernel logs or just trying them on the oldest kernel
> they need? This should probably be solved by some upper layer management
> app which would collect feature sets from all hosts and come up with a
> common subset. I'm not sure if this is done by some tools already.
I specifically didn't talk in terms of features, because the problem you
describe is unreasonable to push onto applications.
Rather QEMU could express host baseline
- "host-v1" - features A and B
- "host-v2" - features A, B and C
- "host-v3" - features A, B, C, D, E and f
The mgmt app / admin only has to know which QEMU host baselines their
Essentially this could be viewed as separating the host kernel dependant
bits out of the machine type, into a separate configuration axis.
|: 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 :|
next prev parent reply other threads:[~2021-04-21 9:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 15:19 [PATCH 0/2] i386: Fix interrupt based Async PF enablement Vitaly Kuznetsov
2021-04-01 15:19 ` [PATCH 1/2] i386: Add 'kvm-asyncpf-int' to kvm_default_props array Vitaly Kuznetsov
2021-04-01 15:19 ` [PATCH 2/2] i386: Disable 'kvm-asyncpf-int' feature for machine types <= 5.1 Vitaly Kuznetsov
2021-04-01 15:57 ` [PATCH 0/2] i386: Fix interrupt based Async PF enablement Paolo Bonzini
2021-04-06 11:42 ` Vitaly Kuznetsov
2021-04-08 12:46 ` Paolo Bonzini
2021-04-15 19:14 ` Dr. David Alan Gilbert
2021-04-20 17:35 ` Eduardo Habkost
2021-04-21 8:38 ` Vitaly Kuznetsov
2021-04-21 8:50 ` Daniel P. Berrangé
2021-04-21 9:23 ` Dr. David Alan Gilbert
2021-04-21 9:29 ` Vitaly Kuznetsov
2021-04-21 9:34 ` Dr. David Alan Gilbert
2021-04-21 9:37 ` Daniel P. Berrangé [this message]
2021-04-21 9:48 ` Vitaly Kuznetsov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).